ロードマップでわかる！当世プロセッサー事情 第607回

Rocket Lakeが14nmプロセスを採用した本当の理由　インテル CPUロードマップ

14nmプロセスを採用した本当の理由は
10nmプロセスにすると性能が下がるから

　簡単にIce Lakeのマイクロアーキテクチャーの特徴(Skylake～Comet Lake世代に対してのアップデート)を並べると以下の項目が挙げられている。

• Out-of-Order実行のために必要なバッファ類を増やし、より同時に多数の命令をIn-Flight状態におけるようにした
• 命令デコード幅を4 x86命令→5 x86命令に、命令発行(microOp)を8命令/サイクルから10命令/サイクルに拡張
• AVX512命令をサポート
• AES-NI命令のピークスループットを2倍に拡大
• Rep Move Strings命令の高速化
• L1データキャッシュを32KB→48KBに拡大
• ロードの際の実効レイテンシーを削減
• Data L1へのストアの発行を1回/サイクルから2回/サイクルに強化
• データプリフェッチの機能を強化
• L2 TLBを拡大
• μOpキャッシュの容量を拡大
• 分岐予測機構を強化
• シングルスレッドモードにおけるLarge Page ITLBのサイズを倍増
• L2を大容量化(256KB→512KB)

　ちなみにL3キャッシュはマイクロアーキテクチャーの外にあるが、Ice Lakeベースの第10世代Core iプロセッサーの場合は原則2MB/コアとなっており、おそらくではあるがこれをそのまま引き継ぐ(つまり8コア製品なら16MB)だろう。

　ところでイッペイ氏は14nmプロセスを利用した理由について「長年培ってきた14nm製造技術で、多数のコア（ノートPC向けの8コアはまだ市場に存在しない）を安定して高クロックで動かせるという。」という巧緻な言い方で説明したが、ぶっちゃけると現状のインテルの10nmプロセスは、まだ14nmほどの動作周波数を達成できない。簡単にまとめれば以下のようになる。

インテルのプロセスルール
プロセス	概要
10nm (10nm-?)	Cannon Lakeで利用。まともに動かず、GPUを無効化して出荷されたほど。すでにインテルの中ではなかったことにされている。
10nm+	Ice Lake。モバイル向け、およびXeon向けの多コア製品では利用されるが、動作周波数がさっぱり上がらない(上げることは不可能ではないが、猛烈に消費電力が増える)。最近インテルはこれを10nmとしている
10nm++ (10nm SuperFin)	Tiger Lakeで利用。10nm+よりは動作周波数は向上したが、デスクトップ向けに使えるほどにはあがっていない。
10nm+++ (10nm Enhanced SuperFin)	「おそらく」Sapphire RapidsやAlder Lakeなどでも使われるほか、HPC向けのPonte VecchioのRambo Cache Tileに採用されることが明らかになっている。この10nm Enhanced SuperFinで、現在の14nm++と同等まで動作周波数が上がるとみられる。

　仮にデスクトップ向けに10nmプロセスで製品を投入するとすれば、10nm Enhanced SuperFinを使わない限り動作周波数は低めに留めざるを得ず、IPCはともかくとして絶対性能は確実に下がることになる。現状まだ10nm Enhanced SuperFinは量産に至っておらず、これが量産開始になるのを待っていたらさらに1年後ろにずれかねない。

　するとAMDのZen 4と戦う羽目になるわけで、これはどう考えても勝ち目がない。コストおよび消費電力で不利だとしても14nmで投入するしかない、というところまで追いつめられた結果というのが正確なところである。

　そういえば前回のインテルCPUロードマップの記事で、Rocket Lakeのダイサイズを「8コアで220mm²前後ではないか？」と推定した。これはメモリーコントローラーのPHY部分のサイズは変わらないだろうという前提のもとの数字であるが、もっと激しく大きくなっているという可能性も出てきた。

　3月11日にoverclock.netのフォーラムに投稿された記事に添付された写真を見る限り、ダイサイズはほぼ270mm²近いと推察される。

　もちろんこの投稿が正しいという保証はどこにもないのだが、そもそも筆者の推定の前提が正しいという保証もない(実際メモリーコントローラー周りはいろいろ変更が入った模様だ)わけで、このあたりはもう少し様子を見る必要があるだろう。

AVXの無効化で消費電力が大幅減
ただしアプリがクラッシュする恐れも

　Rocket Lakeではもう1つ、オーバークロック周りについて。ジサトライッペイ氏によるレポートにあるスライドに「AVX有効化・無効化オプション」という表記があるが、これは確認したところ「リアルタイムに」AVXの有効化/無効化を(再起動なしに)できるらしい。

Rocket Lakeで新たに追加されたオーバークロック機能に関するスライド。真ん中あたりに「AVX有効化・無効化オプション」という表記がある

　メモリー周りのパラメーターも同じくリアルタイムで変更可能なのであり得る話なのだが、気になるのはCPUIDだ。CPUIDというのはすべてのx86プロセッサーが持つ、CPUの機能の一覧がまとめられている内部レジスターで、AVXについてもある内部レジスターのあるbitが1なら有効、0なら無効になる(AVX以外にもさまざまな拡張命令を使う/使わないの設定がここにまとめられている)。

　アプリケーションはこのbitを確認してAVX命令を発行する/しないを決めるわけだが、動的に変化するというのはこのbitもダイナミックに変わるのか？　を確認したところ、調べないとわからないという話で現時点では回答が戻ってきていない。

　また、例えばAVXを有効化した状態でAVX命令を使うプログラム(エンコーダーなど)を立ち上げおいて、AVXを無効化した後でプログラムを実行するとどうなるか？　と確認したら、「クラッシュするかもしれないですね」という返答であった。

　確かにAVXユニットの消費電力は、特にAVX512をサポートとなるとかなり大きいので、これを無効化できれば消費電力の低減には役立ちそう(オーバークロック動作時には、これを無効にするとより高い動作周波数が期待できそう)ではあるのだが、その一方で容易にアプリケーションがクラッシュしそうな機能なだけに、使い方には注意してほしい。

2021年4月4日追記

　その後インテルより正式な回答として以下の返答が届いた。

　「AVXの無効化機能については、リリース版では再起動を必要とする仕様で固まりました。また、AVXの無効化機能は、オーバークロック上級者向けの機能です。AVXを使用しているアプリケーションについては、実行前にチェックし実行できないようにしますが、すべてのアプリケーションでチェックがかかるわけではないため、あくまで上級者向けの機能とご理解ください。」

　やはりダイナミックにAVXの有効化/無効化を許すのは危険すぎると判断されたようだ。したがって、オーバークロックツールからこれを設定しても、再起動するまで反映されないようだ。将来のBIOS更新で、BIOS設定にこの機能が追加されることになるかもしれない。

　ちなみに回答の後半の意味は「AVXを有効化/無効化すると、これにあわせてCPUID Flagの当該bitがOn/Offするので、これで現状AVXが有効か否かを判断できる」ということである。通常AVXを利用するアプリケーションはこれを利用してAVXが使えるかどうか判断するので、その意味ではごく穏当な実装になったと言える。