IDF Fall 2010 - 「Sandy Bridge」アーキテクチャの詳細 - IDFで判明した情報を総括

今回のIDFで次世代マイクロアーキテクチャである「Sandy Bridge」の詳細がはっきりした。セッションの内容などを元にSandy Bridgeの詳細を見ていくことにしよう。

Sandy Bridgeは、Nehalemマイクロアーキテクチャの後継にあたるが、同一ダイ上にGPUを搭載しているなど大きく構成が違う。Nehalem系でも同一パッケージ上にGPUを搭載していたが、別ダイであり、単にメモリを共有していただけにすぎなかった。

図01は、Sandy Bridge全体のブロックダイアグラムである。これを見ると、キャッシュ(LLC: Last Level Cache)とSystem Agent、そしてGPUがリングバスで接続されている。このリングバス接続が、Sandy Bridgeのポイントであり、その名前の由来につながるという。この構成は、CPUコアの増減に柔軟に対応可能という特徴がある。LLCは、コアごとに別れてはいるが、このリングバスによりコア、GPU、System Agent間で「共有」されている。というのは、このリングバスにメモリアクセスのリクエストをブロードキャストすれば、LLCのどれかにキャッシュされているならば、これをアクセスできるからである。

搭載されているGPUには、メディア処理の機能が含まれており、ビデオのエンコード、デコードをハードウェアで実行できる。このメディア機能は、高速に処理し、アイドル時間を長くすることで消費電力を押さえるという思想で開発されているため、通常のビデオ再生などの場合には低消費電力で動作するが、メディア変換のような場合には、高速で処理を行うことを可能にする。

さらに従来のSSEの2倍の256bit幅のSIMD命令であるAVX命令が搭載されており、SSEに対して1.5～2.5倍の性能向上が可能になっている。

もう1つは、Turbo Boost機能の強化がある。Turbo Booostは、CPUパッケージ全体で消費電力や発熱量を管理し、上限に余裕のある場合には、クロック周波数を上げて、処理性能を短時間であるが向上させる技術。今回のSandy Bridgeでは、CPUにGPUが統合され、従来でいえばCPU+GPUという枠で電力や温度を管理するようになった。Nehalem系では、CPUとGPUの消費電力、温度は別管理になっていてた。このため、たとえばグラフィックス処理の負荷が低い場合には、従来よりも上限が上がるためより高い周波数で動作させることが可能になった(図02)。

さらに、アイドルが続いたあどなどコア温度が十分低かった場合には、ターボ状態をTDPを越えて設定し、段階的に戻してTDPに近づけるというアルゴリズムが使われており、従来よりもターボ状態を高くすることが可能になっている(図03)。

性能向上の要素は多いが、AVXやメディア機能に関しては、対応したプログラムが必要であり、従来のままではその恩恵を受けることはできないが、アプリケーションのバージョンアップなどにより、AVXやメディア機能への対応が進めば高い性能を享受できるようになりそうだ。

とはいえ、CPUである以上、コア部分の性能強化がどうなっているのかが一番のポイントだ。Sandy Bridgeはフルスクラッチからの設計ではなく、従来のCore/Core2の設計をベースにしているが、大幅な改良が加えられている。

Sandy Bridgeのコアは、命令フェッチからデコード、そしてOut Of Order(OoO)実行部へ命令を発効する「In order」部と、OoOでμopを実行するOut order部に大きく別れる(図04)。まずは、L1キャッシュからデコーダーまでとなるFront End部を見ていくことにしよう。

Front End部は、L1命令キャッシュ(32K)、プレデコード部、デコーダー、分岐予測ユニットなどからなる(図05)。高速化のため、デコーダーでIA32命令から変換されたμopは、キャッシュに入れられる。くり返しなどで同じ部分を何度も実行するような場合には、このμopキャッシュが使われ、再度デコードなどを行う必要はない。このあたりの制御は、分岐予測ユニット側で行っているようだ。また、特定部分をくり返し実行している場合、デコーダーまでの部分は、先の部分のデコードを続けるか、後段部分がくり返し実行などで新たにμopを受け入れることができない場合には、電源を切って休眠状態に入ることができるという。

このμopキャッシュは、L0 Instruction Cacheとも呼ばれている。コア外にあるキャッシュがLLC(Last Level Cache)と呼ばれているのは、データと命令が分離していて、段数が違うなどの理由でL3キャッシュとはいわないようだ。

このL0キャッシュは、単なるキャッシュではなく、分岐した場合に命令をつなぎ合わせることが可能で、いわゆるトレースキャッシュである。インテルによれば、L0命令キャッシュは、多くのアプリケーションで80%程度のヒット率があるという。キャッシュは、後段に対して32bytes/cycleでの出力が可能で、ほぼ4命令を同時に供給できるのだという。

こうして変換、キャッシュされたμopは、「Allocation/Rename/Reirement」ユニットに入る。ここは、μopに対して後段となるOoO部のスケジューラへ命令を渡したり、レジスタリネーミングの管理、そしてOoO実行された命令の後始末を行う部分。ここには、従来よりも大きなバッファがある。また、レジスタリネーミング機構は、コミットされた命令による現在の状態に対応する「Retirement Register File(RRF)」を使わず、物理レジスタファイルを使う方式に変わった。このため、レジスタに書き込んだ値を他の場所(たとえばRRF)に書き込む必要がない分高速な処理が期待できる。

また、メモリアクセスのためのLoad Buffer、Store Bufferは、Nehalemに対して増えており、より多くのエントリを記憶できる(図06)。

ここに新機能として「Zeroing Idioms」がある。x86系でのZero Idiomとは、レジスタをゼロにするようなXOR EAX,EAXなどの命令のことをいう。この命令はオペランドを持たず、高速に実行でき、EAXにゼロをロードするよりも早いからである。しかも、この命令は、レジスタの以前の値に関わらず常に一定の結果(ゼロ)となる命令である。「Zeroing Idioms」とは、おそらく、こうした命令を正直に演算するのではなく、単にレジスタクリアしてしまうような動作を行わせるものではないかと思われる。この処理はμopを実行ポートへ転送するスケジューラの段階で行われるため、μopは、ポートには発行されず、リネーミング機構でのゼロクリアとレジスタ確保だけおこなうようだ(図07)。

Out of Order(OoO)部は、命令のスケジューラと3つの実行ポート、3つのロード/ストアポートだ(図08)。まず実行ポートだが、ここに256bitのSIMD演算機構が導入された。実行ポートの演算機構は、汎用整数、整数ベクトル、浮動小数点ベクトルの3つの部分を持つ。このうち、整数ベクトル、浮動小数点ベクトルは、ポートにより別の演算機構を持つ。Sandy Bridgeでは、ここに整数、浮動小数点演算の可能な256bitの演算機構が導入されており、単純に見ると従来SSEの倍の演算を一回で行うことが可能になっている。ただし、これは演算器のレベルの話で、実際には、途中にメモリへのアクセスや条件判断などの非AVX命令の実行も入るため単純に2倍というわけではない。たとえば、行列の転置(縦横の並びを変える)のようなものでは従来のSSEの2.53倍としているが、単純な行列の加算では1.43倍に止まる(図09)。なお、従来の128bitのSSE演算も一部256bitの演算機構を使って行われる。ただし、この場合、上位の128bitを使っている(非ゼロが書き込まれている)と、256bitのデータが保持されていると判断されるため、SSE 128bit命令の実行を行うときに上位データをセーブし、再度、256bit AVX命令を実行するときにこれをリストアする。このデータのセーブ、リストアのためのペナルティがあり、実行速度に影響が出る。

ロード/ストアのポートは、3つ。うち2つがロードとストアアドレス生成が可能で、1つがデータストア用である。これにより、1クロックで16バイトまでの2つのデータの読み出しと1つのデータ書き込みを行うことが可能になった。AVXは、256bitつまり32bytesのメモリを一気に読み書きするが、これは、16bytes(128bit)のアクセスを2回行うことで処理される。この処理は、μopとしては1つだが、Load/Storeポートで2回に分けられ、2つのLoadポートを同時に使うようにはならない。このため、高速化するには、256bitを一気に読むよりも128bit(16bytes)を読んだ後、インサート命令を使って後半128bitを読み込むほうが、高速になることがあるようだ。

データには、256Kbytesの二次キャッシュ(MLC: Mid Level Cache)と32Kbytes×8wayのL1キャッシュがあり、フィルバッファーを介して接続している。ここに対して、メモリ制御部とL1は、48bytes(16bytes×3)/クロックで接続されており、さらにメモリ制御部に前記ポートが接続している(図10)。また、ストアデータを保持するStore Bufferも36エントリに増えている。