●モジュラリティが極めて高いSandy Bridgeの内部アーキテクチャ

　Intelの次世代CPUアーキテクチャ「Sandy Bridge(サンディブリッジ)」は、従来の設計思想の延長でパフォーマンスを引き上げたCPUだ。IntelはSandy Bridgeのパフォーマンスに非常に自信を持っており、来年(2011年)には一気にPC市場に浸透させる見込みだ。

　Sandy BridgeのクライアントPC向け製品は4コアと2コアの2バージョンで、どちらもGPUコアをオンダイで内蔵する。Sandy Bridge 4コアの場合は、4個のCPUコアと、共有のLLキャッシュ(Last Level Cache)、1ブロックのGPUコア、DDR3メモリコントローラ、PCI Express、DMI、ディスプレイインターフェイス、そして各ブロックを制御するシステムエージェントを搭載する。共有LLキャッシュは4個の“スライス(Slice)”に分割されており、それぞれCPUコアに付属している。1個のCPUコアと1スライスのLLキャッシュで1つのCPU&キャッシュブロックを構成している。

　Sandy Bridgeファミリはいずれもオンチップのインターコネクトにリングバスを採用している。Sandy Bridge 4コアの場合は、4個のCPU&キャッシュブロックと、GPUコア、そしてシステムエージェントがリングバスに接続されている。リングは合計6ストップと見られ、4重のリングとなっている。

　Sandy Bridge 2コアの場合は、CPUコア&キャッシュブロックが2個に減るが、リングバスを使う構造は同じだ。リングを使った接続性の高い設計のため、IntelはCPUコア数をある程度自由に増やすことができる。4コアと2コアの2バージョンの他に、8コアバージョンの製品群(Sandy Bridge-EN/EP/EX)も準備されている。上位の8コア製品群は、GPUコアを備えない代わりに、リングバスに8個のCPUコア&キャッシュブロックを接続していると推測される。

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

●リアリークールなフィーチャが加わったSandy Bridge

　Sandy BridgeのCPUコアは、基本アーキテクチャはNehalem(ネヘイレム)系と同じくCore Microarchitecture(Core MA)の発展系だ。フロムスクラッチ(真っさらから)開発されたアーキテクチャではない。しかし、新命令セット拡張「AVX(Advanced Vector Extensions)」の実装など、多くの拡張がなされており、かなりの性能向上が図られている。特に目立つのは、AVXによるベクタ演算性能の向上だけでなく、シングルスレッド性能の向上にも力を入れている点だ。

　CPUコアで拡張されたポイントは大きくわけて4つ。(1)フロントエンドクラスタでのuOPキャッシュの追加、(2)実行エンジンクラスタでのAVXユニットの実装と再編成、(3)物理レジスタファイルへの移行とスケジューリングのリソースの強化、(4)メモリクラスタでのロード/ストア機能の強化。特に、フロントエンドに新設されたuOPキャッシュは、シングルスレッドパフォーマンスの向上に大きく寄与すると思われる。実行クラスタとメモリクラスタでの強化は、主にAVXのベクタ演算の性能に効果があると見られる。

　Intelはこれらのマイクロアーキテクチャ拡張を2つに分けている。“クール”と“リアリークール(本当にクール)”の2段階だ。クールなマイクロアーキテクチャ拡張は、その拡張によって増える電力以上のパフォーマンス向上が得られるもの。つまり、消費電力が10%増えても10%以上パフォーマンスが上がるフィーチャだ。Intelは、Nehalem設計の際にこの原則を作り、電力比率の悪いアーキテクチャ改良は行なわなかった。結果としてNehalemでは全体の電力当たりの性能が1.3倍に伸びた。

　それに対してリアリークールなマイクロアーキテクチャ拡張は、消費電力を減らしながらパフォーマンスを引き上げるフィーチャとなる。電力を減らしてパフォーマンスが増えるため、パフォーマンス/電力を大きく押し上げる。Sandy Bridgeでは、リアリークールなフィーチャが加わったことが重要だという。

　下が現在わかっている範囲でのSandy Bridgeのブロック図と、Nehalemのブロック図だ。

Nehalemアーキテクチャ ブロックダイヤグラム PDF版はこちら

Sandy Bridgeアーキテクチャ ブロックダイヤグラム PDF版はこちら

●パイプライン全体に渡るアーキテクチャ拡張

　Sandy Bridge CPUコアの拡張の中で、リアリークールな機能は、フロントエンドの「uOP(マイクロオペレーション)キャッシュ(uOP Cache)」だ。理由は簡単で、uOPキャッシュが、x86命令のデコードという、電力とパフォーマンス両方でのボトルネックを回避できるからだ。キャッシュの後段の実行エンジンが実行するuOPsが、uOPキャッシュにヒットした場合、uOPsはキャッシュから読み出される。大きなx86命令デコーダは何もする必要がなくスリープできる(または、別スレッドの命令をデコードできる)。

　実行クラスタでは、従来の128-bit幅のSIMD(Single Instruction, Multiple Data)演算ユニットであるSSEユニットに加えて、256-bit幅のAVXユニットが実装された。Intelは、命令セットを256-bit幅に拡張しても、実行ユニットは128-bit幅のままで2サイクルスループットでAVX命令を実行することもできた。実際、SSEでは、最初はそうした実装を行っていた。しかし、AVXでは最初から256-bit幅で、フルスピードを出せる実行ユニットを実装した。そのために、Intelは巧みに既存の実行ユニットやデータパスを利用している。

　また、AVXの実装に合わせて、Intelは実行エンジンクラスタの命令スケジューリングのリソースも大幅に拡張した。Sandy Bridgeもアウトオブオーダー型の実行エンジンで、多数の命令を並列に並べ替えて実行できる。Sandy Bridgeではより多くの命令を並べ替え、より多くのストアとロードをバッファできる。つまり、エンジンの性能をより引き出せるようになった。また、レジスタファイルを物理レジスタファイルにリネーミングする方式へと転換することで、データの移動を最小化し、電力の削減と性能の向上を図った。

　AVXでSIMDユニットの演算能力が2倍になれば、2倍のデータが必要となる。そのため、Intelはメモリクラスタでのメモリをハンドルする機能を高めた。従来のNehalemはロードとストアのパイプラインが分離されていた。しかし、Sandy Bridgeではロード/ストアの両対応ユニットとし、L1データキャッシュのポートも拡張して、最大2つの16bytesロードと、1つの16bytesストアを並列に行なえるようにした。ロードの方が多いのは、実行エンジンの実際の使用はロードの方がずっと多いからだ。

　こうした改良の結果、Sandy Bridgeは、整数演算とSIMD浮動小数点演算のどちらでも性能が高いCPUとなったという。

●uOPsをキャッシュすることで効率をアップする

　Sandy Bridge CPUコアのフロントエンドクラスタ、つまり、命令をメモリから取ってきて実行できるようにするまでの部分は、非常に複雑で強力だ。これは、命令セットが複雑なx86 CPUでは、命令の実行自体よりも命令のフェッチ(取り込み)とデコードがボトルネックになりやすいからだ。Intelは、Core MAでこの部分を非常に強化したが、NehalemやSandy Bridgeでも継続して強化し続けている。すでに述べたように、その中でも目玉はuOPキャッシュ(uOP Cache)で、電力消費を減らしつつ、パフォーマンスをアップできたという。

　ほとんどのx86系CPUは、x86命令をCPU内部命令「uOP」にデコードして実行する。x86 CPUでは、x86命令からuOPへのデコードが非常に重荷であり、CPUの中でもダイ面積を取り、電力を消費する源となっている。そのため、x86命令デコードの部分をスキップできれば、パフォーマンスも上がり、電力消費も減る。Intelは、この原則に従うことで、Sandy Bridgeのフロントエンドを大きく改良した。つまり、デコードしたuOPsをキャッシュしてしまうことで、デコードしなくても済むようにした。

　Sandy Bridgeでは、1.5K分のuOPsを保持できるuOPキャッシュをデコーダの後段に備えている。これは1.5KB分の命令ではなく、約1,500個分のuOPsを格納する。Intelはこの1.5K分のuOPsしか保持しないuOPキャッシュで、80%のキャッシュヒット率を達成できると説明している。命令デコーダは、20%しか使われないことになる。ここはポイントで、8割の確率でデコーダをスキップできれば、CPUパフォーマンスは格段に上がるはずだ。特に、パフォーマンス向上が難しい整数演算で向上が期待できる点が大きい。ただし、Intelは、まだuOPキャッシュでの80%の根拠となる詳しいデータは明らかにしていない。この通りだとしたら、サイズの割に効率が良いキャッシュとなる。

　また、このuOPキャッシュは、単純なキャッシュではなく、命令フローの中の分岐を超えて、命令フローを連結させることができる。つまり、実際に実行される命令(分岐命令を含む)のトレース(軌跡)に沿って、キャッシュにuOPを格納できる、トレースキャッシュ的な仕組みとなっている。キャッシュラインを読み出すと、分岐をまたいだ実行トレースでuOPがフェッチされることになり、原理的には効率が上がるはずだ(条件分岐の結果が異なると効率が落ちる)。そもそも、uOPのキャッシュになると、通常の命令キャッシュのように、キャッシュライン毎にメモリ上の静的な命令の並びをキャッシュするわけではない。推定されるSandy Bridgeのフロントエンドの仕組みは次のようになっている。

フェッチとデコード PDF版はこちら

●Intelにとって3度目となるuOPsのキャッシュ

　IntelがuOPsをキャッシュする試みは、これで3度目だ。まず、NetBurst(Pentium 4)アーキテクチャで12KのuOPsを格納するトレースキャッシュをL1命令キャッシュの代わりに採用。次に、Nehalemで28個のuOPsを格納する小さなループストリームディテクタバッファ(Loop Stream Detector Buffer)を設けた。実際はキャッシュではなく、uOPsのキューをうまく利用する仕組みだが、uOPsの再利用という点では目的は同じだ。ちなみに、このコラムでは、Nehalemの説明の際に、次のマイクロアーキテクチャでは、大きなuOPキャッシュを搭載すると予想したが、その通りになった。もっとも、この予想は、Intelの設計思想からすれば当然の結果だ。ちなみに、AMDのBulldozer(ブルドーザ)でも、似たようなキャッシュを搭載するという噂があったが、実際に搭載したのはIntelの方だった。

キャッシュ階層の変化 PDF版はこちら

　また、キャッシュの改良に合わせて、IntelはSandy Bridgeの分岐予測も一新したと説明している。ただし、詳細はほとんど公開しておらず、分岐ターゲットのバッファが2倍になったことや、ヒストリバッファがより効率的になったことなどだけが明かされている。ちなみに、IntelはNehalemでは分岐予測ユニットを2階層化した。1段目は小さなコードフットプリントの予測を迅速に行ない、2段目は大きなフットプリントの予測を行なう仕組みとなっていた。

　こうして見ると、Intelは依然として、このフロントエンド部分の改良に力を注いでいることがわかる。Pentium M(Banias:バニアス)ではMicro-Fusionで、2つのuOPsを1個に統合したまま内部パイプラインで扱えるようにした。Core MAではマクロフュージョン(Macro-Fusion)を導入して、特定の2命令を1命令に融合させることで、命令フェッチ帯域とuOPs帯域を実質的に増やした。NehalemではuOPsベースのループディテクタで、ループ時にデコードステージをスキップできるようにした。

　この流れを見る限り、Intelは今後もこの部分に改良を加えて行くことになるだろう。命令フェッチとデコードが重いのは、x86系命令が複雑であるためだ。Intelの強味はx86命令にあるが、そのための負担がCPUのフロントエンドに重くのしかかっている。Intelは強味を保持するために、フロントエンドの改良に継続して力を注いでいる。ちなみに、Intelは数年前に、この路線の最終形とも受け取れるマイクロアーキテクチャ研究「PARROT(Power AwaReness thRough selective dynamically Optimized Traces)」を発表している。PARROTにあるような複雑な仕組みまで行き着くかどうかはわからないが、Intelにはまだフロントエンドの改良の札があることは確かだ。

PARROTのパイプラインコンセプト PDF版はこちら