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

HotChips 33で判明したAlder Lakeの詳細　インテル CPUロードマップ

4命令/サイクルを無理なく実行できる
効率重視のE-Core

　E-Coreのブロック図を、Tremontのものと比較すると、もうほとんど別物と言ってもいい。まずフロントエンド。

Prediction(分岐予測)も強化されたとしているが、この部分の詳細は不明

　構造自体はTremontのもの(https://ascii.jp/elem/000/001/981/1981407/img.html)とよく似ており、3命令/サイクルのデコーダー×2が搭載され、ハイパースレッディング無効時には6命令/サイクルのデコーダーとして動作するのは同じだ。ただし命令キャッシュが32KB→64KBに倍増している。したがってフロントエンドに関して言えば実はP-Coreとピーク性能は変わらない。

この辺りまではTremontの構造をそのまま踏襲している

　もっともP-Coreと異なり、μOp Cacheは未搭載というか、容量がずっと少ないμOpキューになっているあたりはTremontと同じである。容量そのものは現状では不明だが、おそらく1K μOp未満であろう。

　激しく異なるのは発行ポートで、実に17ポート。ROBも8命令幅に増やされており、Tremontと比較して同時発行命令数が大幅に拡張されているのがわかる。

発行ポートは17ポート。RS(Reservation Station)がいくつあるのかは現状不明。256エントリーのOoO Windowと書くあたり、まさかRSを1つに集約したわけではないとは思うのだが……

　実行ユニットは下の画像の通りで、ALU命令が同時4つ、AGUも4つ、Jump×2、Store Data×2、それとVector周りが最大5つである。

実行ユニット。Vector ALUが増強というあたりはAVX2の整数演算系命令強化だと思われる

　P-Coreがx86命令換算で最大5命令/サイクルを処理できると上で書いたが、E-Coreは4命令/サイクルを無理なく実行できる構成としていいだろう。Vector Unitは、ピーク性能はTremontと変わらないが、Tremontの構成が2 Vector Engine+1 Store Dataだったのに対し、E-Coreは3 Vector Engine+2 Store Dataになっており、実効スループットは大幅に上がっていると思われる。

　下の画像がメモリーサブシステムであるが、Tremontと比べてDual Load+Store(TremontはDual Load/Store)で、実効帯域が大幅に上がっているうえ、バッファリングの深さが増えており、より多くの同時Load/Store発行が可能となっている。

Data L1のサイズはTremontと同じく。おそらくはレイテンシーもTremontと同じ3サイクルであろう

　2次キャッシュの容量は(まだAlder Lakeに搭載されるE-Coreの正確な2次キャッシュサイズは未公開)Tremontの最大4.5MBから4MBに削減されているが、Tremont世代ではなかったLLCが控えていることを考えていると、これだけあれば十分という気もしなくはない。

負荷に応じた制御ができる
Thread Director

　Thread Directorの概略は前回説明したが、HotChipsでの説明はこちらがメインであった。まず概略であるが、Intel Architecture Day 2021での説明にはなかった“Power and energy management”が追加されているのがわかる。

Thread Directorには“Power and energy management”が追加されている。つまりプロセッサーごとの負荷以外に、消費電力あるいは発熱の状況に応じてP-CoreからE-Coreへの移動(あるいはその逆)も可能になる。ただ具体的なアルゴリズムなどは今回説明はなかった

　さて、負荷に応じた制御の詳細であるが、まずThread Directorの前提として、スレッドごとに“Class”の割り当てがある。そのClassの割り当て区分が下の画像である。縦軸はP-CoreとE-CoreのIPCの比率であり、要するに同じ処理をP-Coreで実施したらE-Coreの場合に比べてどの程度効率が上がるかである。

Classの割り当て区分。ただ前回も書いたが、例えばドライバー内部のSpin Lockに関しては、OSの側でKernel関連スレッドは強制的にClass 1に割り当てるなどの対応が可能なようだ

　この比率が下表だ。Class 3はSpin Lockなどのケースで、それはE-Coreの方が適切である。

P-Coreで実施したらE-Coreの場合に比べてどの程度効率が上がるの比率とClass分け
比率	Class
1.1～1.4程度	Class 0
1.4～1.5程度	Class 1
1.5以上	Class 2
1.1未満	Class 3

　さて、このClass分けとプロセッサーへの割り当てだが、実はインテルは2018年からEHFI(Enhanced Hardware Feedback Interface)と呼ばれるテーブル構造を用意している。このテーブルは、それぞれのプロセッサーごとに「性能用途向け/エネルギー効率向け」にどれだけ向いているかを値としてハードウェア的に格納しており、これを参照してOSがスケジューリングできるというものだ。

　例えばあるP-Coreが負荷がかかっていない場合、そのプロセッサーのPerfの欄は255、EEは0に設定される。これが負荷が半分位なら、Perfが127、EEは0となり、同様にE-Coreは負荷0ならPerfが0、EEが255で負荷半分ならPerfが0、EEが127といった感じだ。

　このテーブルは定期的に更新されるので、OSのスケジューラーはこのテーブルを見ながらTaskのClassごとに適した(つまりそれぞれの欄の数字が一番高い)プロセッサを選んで割り当てるという仕組みである。

場合によってはスケジューラー側で、TaskのClassを動的に変更することも不可能ではなさそうだ

　ちなみにこのテーブルが更新されたらOSに通知を行なう仕組みもあるし、またこのテーブルを初期化する命令も用意されている。したがってOSのスケジューラーは、あらかじめ自身が管理するスレッドをClass 0～3のどれに相当するかを事前に決めておき、あとはEHFI経由で2つ上のテーブルを参照しながらどのコアに割り当てるか、を決めることになる。

どのスレッドをどのClassに割り当てるかは完全にOS側の処理なので、これにCPUは一切介在しない

　これを利用すると、例えば消費電力や温度が上がった場合、すべてのテーブルのP-Coreのエントリーの数字を0にしてしまい、E-CoreのエントリーのPerfの値を上げてやれば、自動的にP-Coreが使われずにE-Coreのみが稼働することになり、消費電力が下がって発熱も減ることになるわけだ。

　一応説明では、Thread Directorを使うことで、正しくスレッドの割り振りが行なわれて性能が向上するとしているのだが、実際にどの程度改善するのかという具体的な数字は現時点では明らかにされていない。

脚注にもあるように、これは全然正確なスケールではなく、単なるイラストだとしている