解決したいこと

もっと抜本的な方法でマイクロコードを高速化させる。

ということを簡単に言及してみる。

あくまで勝手な考えです。実装するしないはご自由で、これによって発生しうるメーカー等の多大な損害には応じることはできません。

CPUが遅い理由は何？

大昔のCPUは完全にハードウェアだけで構築されていました。

高速であることがメリットでした。ーそれが1MHzの動作クロックであれ

しかし今のCPUは多くがマイクロコード方式となっています。

必然的にマイクロコードで実行すれば、命令をμOPSに変換する手間がかかり、L1キャッシュに一時保存されたとしてもその分の電力（厳密には熱電力）を消費して、その熱電力分、CPUが無駄に動いていることになります。

それではどうすればいいの？

まずはこのとおりになります。

例えば標準的な8コアCPUがあったと仮定します。

これらのコアは高速で直接μOPSを実行することができます。

それとは別に、低速で実行できる命令→μOPS動的変換でき、実行できるコアを用意します。

BIOSでの対応

ちょうど良いことに今ではUEFI-BIOSが主流となっています。

UEFI-BIOSの部分のコードを、ストレージのUEFIにμOPSで保存します。

あわせて、UEFI-BIOSをμOPSにコンパイルするためのコードもUEFI-BIOSに入れておきます。

例えば、ここでは

I社のC-Core12シリーズ
A社のR-Zen3シリーズ

とかいうふうに、おおざっぱにコンパイラを用意します。

OSでの対応

Windowsであれば、おそらくマザーボードを変えたらインストールしたWindowsが動かず、再インストール対応をしないといけないのは、みなさんご存じかもしれません

Linuxであれば標準カーネルを使用していれば動くといえば動きますが、それは置いてといて・・・

OSはUEFI-BIOSからロードしたコンパイラを用いて、OS自身をμOPSにコンパイルすれば良いことになります。

保存先は普通にアクセス不能なプログラムと同一のドライブにおいておけばよいでしょう。

（Linuxとかの場合、同一のマウントされているドライブ）

PHPも動的にコンパイルしてOPをキャッシュできますが、それと全く同じことになります。

あわせて、OSがUpdateするごとに（Windows Updateとか）、OSが所持するCPUコンパイラもアップグレードされることになります。

ここでは更にチューニングするために

I社のC-Core12800
I社のC-Core12600
A社のR-5950X
A社のR-5800X

とかいうふうに、個々のCPUのコア数に応じて、最適化コンパイラを提供します。

※さすがにクロック周波数の差異ではそこまではいらないかとは思いますが、CPUキャッシュの容量には応じてコンパイラは提供する必要があるでしょう。

※もちろん、これはコンパイルオプションを変えるだけで良いと思われます。

CPUコンパイラを用意するだけで

μOPSをキャッシュして実行できた分だけではむしろメモリバスが分散化されたμOPS命令に埋められて、低速化はします。

しかし現代のプログラムではL1キャッシュの容量を遥かに超えたプログラムが主流で、かつ、非常に多くのプログラムがマルチタスクで動作することで、目に見えない速さでCPUのキャッシュの内容が高頻度に切り替わってることにより、30%程度の高速化、もしくは10%程度の低電力もしくは低発熱が実現できるのではないかと勝手に考えています。

しかし、CPUコンパイラを実装するのは非常に困難を極めるかと考えられます。

CPUコンパイラの長所

高速化

もちろん、CPU命令を動的変換（デコード）するオーバーヘッドによって、熱電力を削減するだけではなく、デコード分のわずかなクロックも節減でき、高速化することができます。

（いくらパイプラインでデコードされるとはいえ）

デコーダー分のウェハーの節約

デコーダーを最小限のコアだけにすることによって、その分CPUキャッシュの容量を少しでも増やして、高速化することができます。

新たな命令を容易に実装

極端な例かもしれませんが

たとえばAVX-4096 という新しいCPU命令が出たと仮定しましょう。

それをCPUコンパイラのアップデートによって、直接該当するCPUに対して最適な命令に置き換えることができます。

今では使われませんが

AMDの3DNowをIntelで使いたい

とかいうことも可能になります。

エラッタにも強い

万が一CPUにエラッタが出ても、従来では直接マイクロコードに対して回避命令を書き込むのとは異なり、コンパイラがエラッタが出ないコードを直接再生成することになります。

継続的なCPUのアップデート

買ったらそれ以上性能が一切上がらない（オーバークロックは置いて）CPUを、無料でコンパイラのアップデートにより、より高速なμOPSを出力できる可能性を見出せます。

CPUコンパイラの難点

メモリバスを消費する

メモリバスが命令をμOPSに展開した分消耗します。
→DDR5もでるし。

キャッシュメモリを消費する

もともとμOPSに変換せず保存していたCPUキャッシュがμOPSに展開した分消耗します。
→AMDの3D-VCacheもでるし

ストレージを消費・消耗する

ストレージがμOPSに変換した分、多大に消耗します。
→SSDも初期と比べて消耗頻度が減り、かつ大容量化している

コンパイルに時間がかかる

→基本的にインストールプロセスで行なうのであまり問題ないが、明示的なインストール作業を行っていない野良プログラムの問題も

セキュリティーリスクがある

→本記事最下部を参照

FAQ

それってItaniumでやろうとしてたことと同じような感じ？

CPUの黒歴史として有名なItaniumでやろうとしていた、分岐予測をCコンパイラでやろうとしていたこととは全く異なります。

Itaniumで行おうとしていたのは開発時に行う分岐予測であって、今回提案しているのは、すべてのエンドユーザーの元でコンパイルを行うものです。

もともとRISCに近いCPUでは効果あるの？

効果あるかもしれませんが、あまり効果ないです。

CISCから発展し、CISCの極限を極めたx86とx64だけに有効な技術と思われます。

仮想マシンはどう考えるの？

仮想化ソフトウェア側で対応すると同時に、そのゲストマシンでも同様に対応させる必要があります。

セキュリティーはどう担保するの？

このようなCPUコンパイラーを作ってしまえばゆうにセキュリティーアタックの対象になりやすいです。

その為、コンパイルに対するタスクをRing0で実行して保護し、かつ、
セキュアブートでセキュリティーを確保するだけではなく、
OSで生成したコンパイル済μOPSを削除以外アクセス不能にすべきです。

あわせて例えばx86/x64 2台ベンダーのIntel、AMDはもともとμOPSは違うものの、明示的に異なるμOPSを生成・実行できるようにし、
可能であればCPUのシリーズごとにμOPS命令を全く変えてしまう必要があります。

ここでもTPMが有効となり、個体ごとに異なるμOPSを生成するのもありです。

Pコア、EコアあるCPUには有効なの？

実際に所持していませんが、十分に有効と考えます。

むしろ、コンパイル可能なコアは高頻度でコンパイルを行わないために、高効率コアであるEコアにあるべきと考えます。

（UEFI-BIOSはBIOSをアップデートしない限りμOPSを更新する必要がなく、例えばWindowsであればWindowsの起動に必要なμOPSはWindows Update時にしか行われません。また、Windowsのboot直後のファイルシステムの読み込みが完了したら、OSに搭載しているコンパイラが利用できる状態となりますので、Pコア、Eコアでマルチスレッドで高速コンパイルが可能になります）

無料でコンパイラがアップデートされることによって、損失は起きるの？

直接的な考えでいえば、損失は起きます。

しかし、そのCPUをどこまでアップデートして高速化できることによりCPUメーカーの技術的により問われますので、今後も高速にアップデートしてくれるという期待から、将来的にCPUのアップデート力、という期待性を受けることになります。