Sandy BridgeのCPUコアには、新たにAVX(Advanced Vector Extensions)の実行エンジンが実装された。AVXは256-bit幅(32-bit単精度なら8way)のSIMD(Single Instruction, Multiple Data)命令を含む。従来のSSEの128-bit幅のSIMDエンジンの2倍のベクタ長となる。IntelでSandy Bridgeのアーキテクトを務めるBob Valentine氏(Senior Principal Engineer)は、「同じ量の命令フローやキャッシュ帯域で2倍の演算ができる。より効率的な命令スタイルだ」と、ベクタ長を2倍にする利点を強調する。

　また、AVXでは、マスクロード/ストアなどの実装で、よりベクタを扱いやすくなったと指摘する。SIMDのデータスロット単位でマスクすることで、コントロールフローの制御を可能にする。

　しかし、256-bit SIMDをハードウェア実装することは簡単ではない。実行エンジンに、従来のSSEの128-bit幅のSIMDエンジンの2倍の幅の実行ユニットとデータパスを実装しなければならないからだ。Valentine氏によると、Sandy Bridgeの開発チームは、その通り実装したら倍のユニットと倍のデータパスが必要になるこの拡張を、もっと手軽に済ませるトリックを見つけたという。それは、既存の実行ユニットとデータパスを拡張してAVXに対応させてしまうことだった。

　現在のNehalem(ネヘイレム)にはSIMD実行エンジンが2スタック存在する。浮動小数点(FP)演算スタックと整数演算スタックだ。「ベクタ浮動小数点とベクタ整数の、並列のハードウェアのスタックがあった。これらのハードウェアは、同じリソースを使わない、分離された実行ハードウェアだった。そこで、この2つの128-bitハードウェアを同時に使えば、256-bitのハードウェアになると思いついた賢いエンジニアがいた」(Valentine氏)。

　下の図の上がNehalemのSIMDエンジン群、下がSandy BridgeのSIMDエンジン群だ。それぞれ3つの命令発行ポートからuOPs(マイクロオペレーションズ:内部命令)が発行される。データキャプチャスケジューラが、オペランドの取りこみと、デスティネーションレジスタへの書き込みを管理する。Nehalemでは、浮動小数点(FP)スタックと整数スタックは命令発行ポートは共有するが、実行エンジン自体は独立している。

AVXの実装 PDF版はこちら

　そこで、IntelはSandy Bridgeではスタックを図の下のように再構成した。AVXの256-bit SIMDをハイとローの2つの128-bit SIMDに分けた。「AVX 256-bitハイ側の半分はレガシの浮動小数点(FP)スタックを、AVX 256-bitロー側の半分はレガシの整数スタックを使う。それによって、AVX 256-bitの加算と乗算の2つをそれぞれ実行する」(Valentine氏)。

　既存の128-bit SIMDハードウェアを拡張して256-bit SIMDを実現したため、完全に新しいエンジンはAVX 256-bitのシャッフルとパミュートエンジンだけで済んだという。

Sandy Bridgeのスタック

浮動小数点の実行

　AVX実装でのもう1つの問題は、SIMDレジスタが128-bit幅から256-bit幅に広がったため、データ移動のムダが目立つようになったことだという。AVXのYMMレジスタは、従来のSSEのXMMレジスタの2倍のサイズとなる。

　通常のOut-of-Order実行エンジンでは、命令実行の結果をリオーダバッファ(ROB)にバッファする。結果をオペランドに使う命令がある場合は、リオーダバッファ(ROB)から読み出してスケジューラにコピーする。最終的に、命令がコミット(完了)すると、結果はリタイヤメントのためのレジスタに書き戻される。この仕組みでは、結果のデータを何度も移動させる必要があった。

　しかし、AVXでレジスタ幅が広がりデータ量が増えると、データ移動によって消費される電力がばかにならない。そのムダを省くため、Sandy Bridgeでは物理レジスタファイル(Physical Register File:PRF)を実装したという。データは物理レジスタファイルに格納され、個々のIA上のレジスタは物理レジスタにリネームされる。結果をオペランドに使う場合は、マップされた物理レジスタから直接データを取りこむ。IntelのValentine氏は、この仕組みを次のように例えた。

　「現在のスケジューラは、オペランドを実行ユニットに送り、演算などの結果をキャプチャする。キャプチャしたデータは、(リオーダバッファに)格納しておき、セントラルプレイスに書き戻す。例えば、ある命令の実行結果を待っているひとかたまりの人(命令)がいるとしよう。あなた(リオーダバッファ)は、結果をキャプチャして、その結果を待っている誰(命令)もが利用できるようにする。その場合、あなた(リオーダバッファ)は、それぞれ(の命令)に、個別に結果を書いたペーパー(データ)をいちいち渡さなければならない。ペーパー(結果)を渡されると、彼ら(命令)はそれをもって(リザベーションステーションに)戻る。これは、あまり効率的なやり方ではない。

　Sandy Bridgeではその代わりに、結果を1カ所(物理レジスタファイル)に置くことにした。命令を実行すると、データはスケジューラの物理レジスタファイルに書き込まれる。もう二度とリタイヤメントのために書き戻されることはない。1コピーのデータが1カ所に1回ストアされるだけだ。

　例えると、結果が出たら、誰(命令)もが一定の場所(物理レジスタ)に結果があると知らされる。彼ら(命令)は、必要ならいつでもその結果を参照できる。これが、我々が実際に成し遂げたことだ」。

　Intelによると、物理レジスタファイルへの移行によって、AVXの実装が容易になったという。2倍ワイドなベクタのデータを扱うためには、電力消費を減らす物理レジスタのような仕組みが必要だったという。Out-of-Order実行中の一時的な結果は、従来はリオーダバッファ(ROB)のバッファに格納されていたのが、物理レジスタに格納されるようになった。その結果、リオーダバッファ(ROB)にデータを格納するバッファはなくなり、実質的に命令のコミット(命令終了)の管理だけを行なうようになったと見られる。

　Nehalemの図では、リオーダバッファ(ROB)の中に、大きなバッファがあり、スケジューラとリオーダバッファの間をデータが移動する。しかし、Sandy Bridgeではリオーダバッファ(ROB)側にはバッファがなくなり、データの移動もなくなっている。Nehalemのデータキャプチャスケジューラは、Sandy Bridgeでは物理レジスタファイル(Physical Register File)に置き換わっている。

Sandy Bridgeのブロックダイアグラム PDF版はこちら

　Sandy Bridgeでは、Out-of-Order実行エンジンのリソースも大幅に広げている。Sandy Bridgeのリオーダバッファ(ROB)のエントリは168で、これはNehalemの128エントリと較べて30%以上多い。NehalemはCore MA(Merom:メロン)の96エントリよりROBが33%大きかったので、アーキテクチャ世代毎に30%ずつ増えていることになる。リザベーションステーション(RS)のエントリもSandy Bridgeは54で、Nehalemの36から50%、Meromの32から68%も増えた。

　命令発行は、ROBとリザベーションステーション(RS)のエントリに空きがあった時になされるので、ROBとRSのエントリが増えると、スケジューリングできる命令数が増えることになる。より多くの命令をスケジュールできれば、並列実行できるチャンスがより増える。このほか、Sandy Bridgeではロード/ストアのバッファも深くなっている。

　「より多くのバッファを持てば、より(スケジューリングの)ウインドウを広くできる。しかし、より多くのストレージとより多くのデータ移動は、電力の増大を意味する。チャレンジは、どうやって電力を抑えながら、全てのバッファを増やすか、という点にある」(Valentine氏)。

物理レジスタファイルベースへの移行

　ここでも、解決策は物理レジスタファイルベースへの移行だったという。物理レジスタファイルに置き換えたことで、データ移動を減らし、ムダを省いたことで、全体のバッファの増加が可能になったという。

　ちなみに、同様に物理レジスタファイルを採用したAMDの次世代アーキテクチャ「Bulldozer(ブルドーザ)」も、各コア当たり128エントリ(モジュール全体で256エントリ)とリオーダバッファ(ROB)を拡張している。物理レジスタは、AMDの低コスト&低消費電力版の「Bobcat(ボブキャット)」でも採用しており、最新CPUでの消費電力低減のトレンドとなっているようだ。

Sandy Bridgeのダイレイアウト PDF版はこちら

　AVXでIntelはベクタのデータ演算幅を128-bitから256-bitへと拡張した。そのため、Intelは2倍のデータを実行エンジンにフィードしなければならなくなった。Nehalem世代までは、メモリオペレーションのパイプラインは3本で、1本がロード、2本がストア。ストアの片方はアドレス生成で、もう片方がデータとなっていた。L1データキャッシュへのアクセス帯域は32bytes/サイクルだった。

　Intelは、Sandy Bridgeではロードの方がより重要として、ロード帯域を2倍にすることにしたという。ロードが充分にフィードできないと、命令実行が停止するためだ。Valentine氏は、従来のbyte/Flop比率を保つためには、ロードを2倍にしなければならなかったと説明する。

　ロード帯域を2倍にするために、Intelは実行ユニットで使ったのとある程度似たようなアプローチを取った。従来のロードユニットとストアのアドレスジェネレータを、それぞれロード/ストアの両対応のパイプに切り替えたという。また、ストアのポートとロードのポートをそれぞれ双方向のポートに切り替えた。

　その結果、Sandy Bridgeは従来の1つの128-bitロードから、2つの128-bitをロードできるようになり、ロード帯域は2倍になった。合計のL1データキャッシュ帯域はロードが128-bit(16-byte)x2、ストアが128-bit(16-byte)x1で、48-byte(384-bit)となった。

　ちなみに、AMDのBulldozerも各整数コアに2本ずつロード/ストア両対応のアドレスジェネレータを備える。また、各整数コア毎に、1サイクルに2つの128-bit(16-byte)のロードと、1つの128-bitのストアが可能となっている。AMDのBulldozerでは、2コアを融合させたCPUモジュールでの積和算ユニットのピークスループットは、単精度で16オペレーション/サイクル。Sandy BridgeはAVXの演算スループットは1コア当たり、単精度で16オペレーション/サイクル。そのため、単純計算ではBulldozerの方が、bytes/Flop比は高くなる。

Sandy Bridgeの概要 PDF版はこちら

AMDアーキテクチャとの比較 PDF版はこちら

Sandy Bridgeのロード/ストアユニット

　実行エンジンとメモリクラスタの拡張に加えて、Intelはフロントエンド、つまり、命令を取りこみ、デコードする部分も強化している。前回の記事のフロントエンドの部分には間違いがあった。内部命令uOPsをキャッシュするuOPキャッシュの構造は、トレース単位ではなく、通常の命令キャッシュ型だ。バッファリングすることで、分岐パスの結合を可能にするという。

　ただし、uOPにした段階で、命令数と命令長は変わってしまうため、キャッシュをどう管理しているのかはわからない。単純にキャッシュライン単位で管理ができないからだ。いずれにせよ、分岐をどう巧妙にハンドルするかが、キャッシュのカギになることは確かだ。IntelのJustin R. Rattner(ジャスティン・R・ラトナー)氏(Intel Senior Fellow, Vice President, Director(Corporate Technology Group)は次のように説明する。

　「Pentium 4のトレースキャッシュは失望を招いた。しかし、分岐をうまくつなげること自体は、悪いアイデアではない。パフォーマンスブーストのために、(Sandy Bridgeの開発チームは)ある程度似たようなアプローチを取っている」。

Sandy Bridgeのマイクロアーキテクチャ

　また、フロントエンドの分岐予測については、Sandy Bridgeは予測の圧縮テクニックを使うという。より長い履歴、より長いメモリの記録を行なうために、部分的に圧縮手法を使うようだ。例えば、分岐のほとんどはシンプルなので、2-bit場合によっては1-bitのタグで済んでしまうケースがあるという。また、分岐ターゲットについては、GBクラスのメモリ空間を渡ってジャンプ先が飛ぶケースは少ない。ほとんどの分岐は、もっと小さな範囲で発生するので、そこでも圧縮が可能だという。

　IntelのValentine氏は、こうしたCPUマイクロアーキテクチャの拡張の結果、Sandy Bridgeでは新しいアプリケーションだけでなく、レガシーのアプリケーションも速くなることを強調した。既存のレガシーのアプリケーションの性能を上げ続けなければならないことは、ソフトウェア資産に頼るIntelにのしかかる呪縛だ。他のCPUベンダーは、この呪縛が、Intel CPUの進歩を遅らせる要因になっていると指摘する。しかし、Intelは、Sandy Bridgeでは、その呪縛の中で、ベクタとスカラ、スレッドの性能のバランスを取って、どの要素も向上させるという方向へと向かっているようだ。