このページの本文へ

Sandy Bridgeこと新Core iシリーズが登場 第2回

詳細解説 これがSandy Bridgeのアーキテクチャーだ

2011年01月06日 11時30分更新

文● 大原雄介(http://www.yusuke-ohara.com/

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

図2 Sandy BridgeのCPUコアの内部構造

 もうひとつの改良点である「Load/Store Addressのスループット強化」も説明しよう。図2を見ると、Port 2とPort 3の両方ともLoadとStore Addressとなっているが、Nehalem世代ではPort 2がLoad、Port 3がStore Addressとなっていた。つまりNehalem世代に比べると、同時に2つの128bit Loadか、2つの128bit Store Addressを発行することが可能になった。

 この強化の一義的な理由はAVXへの対応だ。これにより1サイクルでAVXレジスターのLoadあるいはSaveが可能になった。もちろんこれは非AVXな従来のx86命令、あるいはSSE命令でも効果的であり、これによるIPC※3の改善効果も期待できることになる。
※3 Instructions Per Cycleの略。1サイクル辺りの命令処理数で、命令実行効率を示す。

図4

図4 Nehalem世代のRe-Order Buffer~スケジューラー~ALU

図5

図5 Sandy BridgeのRe-Order Buffer~スケジューラー~ALU

 目立ちにくいかもしれないが、図4と図5でもうひとつ変わっている部分がある。従来までは、データのLoadなりSaveなりを行なうと、それが「Re-Order Buffer」に反映されていた。それがSandy Bridgeでは、すべて単一の「Physical Register File」に収められて、Re-Order Bufferはポインタ(データの位置情報)のみを格納する形に変更されている。これはSandy Bridgeの隠れた大きな変更点のひとつである。

 Nehalem世代までは、図6のように複数のバッファ(A/B/C)が、演算パイプラインと並行に用意されていた。例えば、あるデータを読み込んで演算を行なおうとした場合、以下のような動きになる。

図6

図6 Nehalem世代までのパイプラインとバッファ

  • ①メモリーコントローラーからキャッシュ経由で、Load Buffer(C)に読み込む。
  • ②Loadが完了したら、取り込んだ結果をRetirement Unitに戻す。その際にLoad Buffer(C)の内容をRegister File(A)にコピーする。
  • ③実際に演算するタイミングで、Register File(A)の内容をExecute Unit内のBuffer(B)にコピー。
  • ④Buffer(B)からデータを取り込んで演算する。値が変更されない場合はこれで終わりだが、書き換わった場合はその結果をBuffer(B)に書き戻す。
  • ⑤ ④で値が書き換わった場合、それをRegister File(A)に反映する。

 結果として、3つのバッファ間をデータが行き来しているわけだ。しかし、こうしたデータの移動には、当然余分な消費電力が掛かることになる。そこでSandy Bridgeでは、図7のような構造に内部を変更している。こちらの場合の手順はこうなる。

図7

図7 Sandy Bridgeのパイプラインとバッファ

  • ①データのロード用にRegister File(A)を割り当てて、その情報をポインタに格納。
  • ②格納した情報をメモリーコントローラーに通知。
  • ③通知されたRegister File(A)の場所にデータを読み込んで格納。
  • ④次の命令に合わせて、改めて場所をポインタに指定。
  • ⑤Execute Unitがポインタから場所の通知を受ける。
  • ⑥Register File(A)からデータを読み込んで演算を実行。
  • ⑦必要なら結果をRegister File(A)に書き戻す。

 この方式の場合、手順そのものは煩雑になる。また、従来ならそれぞれ(メモリーコントローラー/Execute/Retirement)のユニットの傍らにバッファを置けたが、Sandy BridgeではRegister File(A)の位置が各ユニットから遠くなるため、物理的な配線遅延が問題になりやすい。

 その反面、あくまでもポインタだけを管理すればいいので、データを書き換えるよりも消費電力が少なく済む。また結果として、必要とされるバッファの数が減るので、その分個々のバッファのエントリ数を増やせるといったメリットがある。

 実際Sandy BridgeとNehalemの各種バッファの数を比較すると以下のようになる。大雑把に比較して、Nehalemから3割程度は同時に保持できるデータ量を増やせるので、性能改善に効果的である。

Sandy Bridge Nehalem
Load Buffer 64 48
Store Buffer 36 32
Scheduler Entry 54 36
ROB(Re-Order Buffer) 168 128

 同様の技法は、省電力性が強く求められる組み込み向けプロセッサーなどでは、すでに採用例がある。また直近では、AMDのモバイル向けCPUコア「Bobcat」が、やはり同様の技法で省電力化を図ることを明らかにしている。だが、Sandy BridgeのようなハイパワーCPUで、この技法を採用した例を、筆者は他に知らない。

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

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

ピックアップ

ASCII.jp RSS2.0 配信中

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