このページの本文へ

前へ 1 2 3 次へ

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

Sierra Forestの内部構造はGracemontとほぼ変わらない インテル CPUロードマップ

2023年09月18日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/) 編集●北村/ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

 前回に引き続き、Hot Chips 2023の発表について解説する。今回はEコアのみで構成される初のXeon ScalableであるSierra Forestの詳細についてだ。

 ちなみにHot Chipsにおけるセッションタイトルは“The Next Generation of High Performance, Energy-Efficient Computing: Intel Xeon Processors Built on Efficient-Core”という長い物であった。

Sierra Forestの内部構造は
Gracemontとほとんど差がない

 まずは基本ブロックの構造を、Alder Lakeに搭載されたGracemontと比較する。Gracemontの内部構造は連載630回で説明しているが、大きなレベルで比較すると、Gracemontの構造とはそれほど差がない印象だ。

Redwood Coveの構造と比較するとシンプルで、Matrix Engineが落ちているのがわかる。PM(Power Management)コントローラーは、単に大きなブロックになっていないだけで入っていると思われる

 デコーダーを含むフロントエンド部は、Gracemontと差がほとんどないように思われる。細かいところでは改良はあるのだろうが、64KBのL1命令キャッシュや同時3命令デコード×2の構成など、基本的な要素は同じである。

 IP QueueやμOp Queueが2つに分離しているあたりも同じで、これはTremont以来のアーキテクチャーをそのまま踏襲しているのがわかる。

デスクトップ向けのGracemontはSMTを無効化して利用していたので、同時6命令処理のデコーダーとして動作していたが、さてSierra Forestの方はどうだろう? 競合であるBergamoが128コアのSMT動作であることを考えると、SMTを有効化して出してきそうな気はする

 バックエンドの先頭部分も、Gracemontのそれと差がない。アロケーションが5命令/サイクル、リタイアメントが8命令/サイクルなのもまったく同じである。In-FlightのWindow Sizeが256というのも同様で、基本的には差がないものと考えられる。

Issue Portの番号まで一緒である。このあたりをいじると最適化が大変になりそうな気もするので、実行ユニットの数が増えない限りは不変だろう

 実行ユニットも同じである。各Issue Portの下に配された実行ユニットの構成もGracemontの実行ユニットとまったく同じである。

個々の実行ユニットの中には多少改善があるかもしれないが、大きな枠で見れば同じままである

 少しだけ差があるのはメモリー・サブシステムである。一見するとGracemontのメモリー・サブシステムと違いがわからないかもしれないが、以下の違いがある。

メモリー・サブシステムの構造そのものは変わらないし、1次データキャッシュが32KBのままなのは少し意外だったが、これで足りる程度の性能でしかないという見方もできる

 まず、2次キャッシュの容量が“Up to 4MB”から“4MB”に決め打ちになった。Gracemont世代では、例えばAlder Lakeは実際にはEコアの共有2次キャッシュは2MB(Raptor Lakeでは4MBに増量)で、Meteor Lake世代はまだ不明だが、連載720回で説明したようにMeteor Lake世代ではSoCタイルの中にも2コアのEコアが搭載される可能性がある。

 このSoCタイル上で動くEコアに大容量の2次キャッシュを割り当てるとは思えないことを考えると、コンシューマー向けのEコアは引き続き構成次第で変更可能な形のまま残されていると思われる。対してSierra Forest向けはサーバー用途ということで4MB決め打ちなのだろう。

 次に、上の画像右上のブロックにあるように、1次データキャッシュのECC保護や、Data Poisioning/Recoverable Machine Check/Local Machine Checkなどのサポート、それと52bitの物理アドレスへの対応が追加された。

 これらはコンシューマー向けでは必要ない(ECCはともかくData Poisioning/Recoverable Machine Check/Local Machine Checkなどは、そのための機構が搭載されていない、あるいは無効化されている)ものだし、4EB(4 Exa Bytes:4096TB)もの物理アドレスへの対応も要らないだろう。

 このあたりはXeon向けならではな感じだが、逆に言えば違いはこれだけしかないので、ほぼGracemontと同じとして差し支えないことになる。

前へ 1 2 3 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン