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

第778回

Lunar LakeではPコアのハイパースレッディングを廃止　インテル CPUロードマップ

　前回はLunar Lakeのプロセスとタイル構造で話が終わってしまったので、今回はもう少し内部の話をしよう。

Lunar LakeはPコア4つとEコア4つの珍しい組み合わせ

　まずは一番の要であるプロセッサーの構造である。Lunar LakeもPコアとEコアの組み合わせであり、その意味ではAlder Lake(Lakefield)以降で採用されているハイブリッド・テクノロジーを継承した構成である。ただそれが4+4という構成なのはやや珍しい。

　もちろん技術的には可能であるのだが、Eコアが4つというのは、これまでの同社のプロセッサーからするとかなり少ないように感じる。おそらくはであるのだが、1つには次回説明するようにEコアの性能が大幅に上がり、性能的にバランスが取れると判断されたのかもしれないし、Eコアを8つにすると面積的に厳しかったのかもしれない。

　だったらPコアの数を2つに減らせば良かったようにも思うのだが、ハイパースレッディングなしでの2コアはコア数というか同時処理スレッド数が不足すると判断されたのかもしれない。なんというか、微妙なバランスを取った構成になっている。

　またMeteor Lakeで搭載されたI/Oタイル上のLow Power EコアはLunar Lakeでは省かれている。その代わりというべきか、EコアそのものがLow Power Configurationで構成されている。N6プロセス上のLP Eコアより、N3BのLP Eコアの方が消費電力が少なかったのかもしれない。結果としてパワーマネジメント系はMeteor Lakeとまったく異なるものになっている。

　そのあたりの話はいずれ話をするとして、まずはPコアとEコアについて。今回PコアはLion Cove、EコアはSkymontと呼ばれるコアがそれぞれ採用されているが、このLion Cove/Skymont共に、従来のコアから大幅に中身が変わっている。

Lion Coveは"アーキテクチャーのオーバーホール"とされるが、オーバーホールというよりも性能の大幅強化という感じではある。もっともオーバーホールらしいところもある

　Alder LakeのGolden CoveからMeteor LakeのRedwood Coveまでは基本同一コアで Golden Cove→Raptor Cove(L2:1.25MB→2MB)→Golden Cove(L1 I-Cache:32KB→64KB) とキャッシュサイズの増量が主要な違い(細かなアップデートは除く)でしかない。

　ということで、Alder Lakeに搭載されたGolden CoveとLion Coveを比較すると下表のように、猛烈に強化されているのがわかる。

Golden CoveとLion Coveの比較
Decode	6 wide→8 wide
MicroCode	2 wide→4 wide
μOp Cache	9 wide→12 wide
Issue	12 port→18 port
ALU	5 wide→6 wide
FPU	3 wide→4 wide

　もう少し細かく見てみよう。まずフロントエンドであるがDecodeは1サイクルあたり8 x86命令を処理可能であり、μOp Cacheは最大12 wideまで拡張されている。以前の説明が正しければ、1つのx86命令は1つないし2つのμOpに分解されるので、μOp Cacheは最低でもx86換算で6命令/サイクル、平均しておそらく9命令/サイクル程度の供給が可能になると思われる。

現状ではμOp Cacheのエントリー数は未発表である。ただスループットが1.33倍になっている以上、容量もそれに合わせて大型化されている可能性が高い

　次にIssue Port周りだが、そもそもポートの数が大幅に増やされ、かつ同時発行命令が増えたことに対応して内部バッファの容量(ROBやInstruction Windowなど)も増量されている。

In-Flight Windowはもう少し大型化しているかと思ったが、逆に言えば(主にポートが埋まっていることで)今までフルに使いきれていなかったのかもしれない

　実行ユニットに関して言えば、Golden CoveではPort 00/01/05をIntegerとVectorで共用、という形になっていたが今回これが分離された。これがスループット向上につながるか？　というと、短期的にはNoである。

Power Savingが今ひとつピンとこないのだが、あるいはポート単位でのパワーコントロールをしているとすればあり得る話である

　例えばAVX命令などで計算を行ない、その結果を格納するような処理では以下の形で処理される。

Vector→ALU→Vector→ALU→...

　Vectorの処理が終わるまでALUが動くことはない。これはVectorの結果を取り込む、あるいは次の計算のためのパラメーターをレジスターにセットするから、Vectorの処理が終わってからでないと意味がないからで、ポートを共用していても別にそこがボトルネックになるわけではないし、ポートを分けても並列度が上がることはない。

　しかし、これスケジューラーの方からすれば1つのポートにALUとVectorがつながっているのはスケジューリングが複雑になるだけだし、スライドにもあるように将来の拡張性を考えたらポートを分離した方が良い、という判断になったものと思われる。