全国高校eスポーツ選手権運営の舞台裏。Bridge(サンディブリッジ)」は、従来の設計思想の延長でパフォーマンスを引き上げたCPUだ。Bridgeのパフォーマンスに非常に自信を持っており、来年(2011年)には一気にPC市場に浸透させる見込みだ。BridgeのクライアントPC向け製品は4コアと2コアの2バージョンで、どちらもGPUコアをオンダイで内蔵する。Express、DMI、ディスプレイインターフェイス、そして各ブロックを制御するシステムエージェントを搭載する。共有LLキャッシュは4個の“スライス(Slice)”に分割されており、それぞれCPUコアに付属している。1個のCPUコアと1スライスのLLキャッシュで1つのCPU&キャッシュブロックを構成している。Bridgeファミリはいずれもオンチップのインターコネクトにリングバスを採用している。4コアの場合は、4個のCPU&キャッシュブロックと、GPUコア、そしてシステムエージェントがリングバスに接続されている。リングは合計6ストップと見られ、4重のリングとなっている。2コアの場合は、CPUコア&キャッシュブロックが2個に減るが、リングバスを使う構造は同じだ。リングを使った接続性の高い設計のため、IntelはCPUコア数をある程度自由に増やすことができる。Bridge-EN/EP/EX)も準備されている。上位の8コア製品群は、GPUコアを備えない代わりに、リングバスに8個のCPUコア&キャッシュブロックを接続していると推測される。フロムスクラッチ(真っさらから)開発されたアーキテクチャではない。Extensions)」の実装など、多くの拡張がなされており、かなりの性能向上が図られている。目立つのは、AVXによるベクタ演算性能の向上だけでなく、シングルスレッド性能の向上にも力を入れている点だ。CPUコアで拡張されたポイントは大きくわけて4つ。(1)フロントエンドクラスタでのuOPキャッシュの追加、(2)実行エンジンクラスタでのAVXユニットの実装と再編成、(3)物理レジスタファイルへの移行とスケジューリングのリソースの強化、(4)メモリクラスタでのロード/ストア機能の強化。フロントエンドに新設されたuOPキャッシュは、シングルスレッドパフォーマンスの向上に大きく寄与すると思われる。実行クラスタとメモリクラスタでの強化は、主にAVXのベクタ演算の性能に効果があると見られる。Intelはこれらのマイクロアーキテクチャ拡張を2つに分けている。“クール”と“リアリークール(本当にクール)”の2段階だ。クールなマイクロアーキテクチャ拡張は、その拡張によって増える電力以上のパフォーマンス向上が得られるもの。消費電力が10%増えても10%以上パフォーマンスが上がるフィーチャだ。Intelは、Nehalem設計の際にこの原則を作り、電力比率の悪いアーキテクチャ改良は行なわなかった。結果としてNehalemでは全体の電力当たりの性能が1.3倍に伸びた。それに対してリアリークールなマイクロアーキテクチャ拡張は、消費電力を減らしながらパフォーマンスを引き上げるフィーチャとなる。電力を減らしてパフォーマンスが増えるため、パフォーマンス/電力を大きく押し上げる。Bridgeでは、リアリークールなフィーチャが加わったことが重要だという。Bridgeのブロック図と、Nehalemのブロック図だ。理由は簡単で、uOPキャッシュが、x86命令のデコードという、電力とパフォーマンス両方でのボトルネックを回避できるからだ。キャッシュの後段の実行エンジンが実行するuOPsが、uOPキャッシュにヒットした場合、uOPsはキャッシュから読み出される。大きなx86命令デコーダは何もする必要がなくスリープできる(または、別スレッドの命令をデコードできる)。Data)演算ユニットであるSSEユニットに加えて、256-bit幅のAVXユニットが実装された。Intelは、命令セットを256-bit幅に拡張しても、実行ユニットは128-bit幅のままで2サイクルスループットでAVX命令を実行することもできた。実際、SSEでは、最初はそうした実装を行っていた。AVXでは最初から256-bit幅で、フルスピードを出せる実行ユニットを実装した。そのために、Intelは巧みに既存の実行ユニットやデータパスを利用している。AVXの実装に合わせて、Intelは実行エンジンクラスタの命令スケジューリングのリソースも大幅に拡張した。Bridgeもアウトオブオーダー型の実行エンジンで、多数の命令を並列に並べ替えて実行できる。Bridgeではより多くの命令を並べ替え、より多くのストアとロードをバッファできる。エンジンの性能をより引き出せるようになった。レジスタファイルを物理レジスタファイルにリネーミングする方式へと転換することで、データの移動を最小化し、電力の削減と性能の向上を図った。AVXでSIMDユニットの演算能力が2倍になれば、2倍のデータが必要となる。そのため、Intelはメモリクラスタでのメモリをハンドルする機能を高めた。従来のNehalemはロードとストアのパイプラインが分離されていた。Bridgeではロード/ストアの両対応ユニットとし、L1データキャッシュのポートも拡張して、最大2つの16bytesロードと、1つの16bytesストアを並列に行なえるようにした。ロードの方が多いのは、実行エンジンの実際の使用はロードの方がずっと多いからだ。Bridgeは、整数演算とSIMD浮動小数点演算のどちらでも性能が高いCPUとなったという。CPUコアのフロントエンドクラスタ、つまり、命令をメモリから取ってきて実行できるようにするまでの部分は、非常に複雑で強力だ。CPUでは、命令の実行自体よりも命令のフェッチ(取り込み)とデコードがボトルネックになりやすいからだ。Bridgeでも継続して強化し続けている。Cache)で、電力消費を減らしつつ、パフォーマンスをアップできたという。ほとんどのx86系CPUは、x86命令をCPU内部命令「uOP」にデコードして実行する。CPUでは、x86命令からuOPへのデコードが非常に重荷であり、CPUの中でもダイ面積を取り、電力を消費する源となっている。そのため、x86命令デコードの部分をスキップできれば、パフォーマンスも上がり、電力消費も減る。Bridgeのフロントエンドを大きく改良した。デコードしたuOPsをキャッシュしてしまうことで、デコードしなくても済むようにした。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のキャッシュになると、通常の命令キャッシュのように、キャッシュライン毎にメモリ上の静的な命令の並びをキャッシュするわけではない。Bridgeのフロントエンドの仕組みは次のようになっている。フェッチとデコードPDF版はこちら●Intelにとって3度目となるuOPsのキャッシュIntelがuOPsをキャッシュする試みは、これで3度目だ。4)アーキテクチャで12KのuOPsを格納するトレースキャッシュをL1命令キャッシュの代わりに採用。Buffer)を設けた。実際はキャッシュではなく、uOPsのキューをうまく利用する仕組みだが、uOPsの再利用という点では目的は同じだ。ちなみに、このコラムでは、Nehalemの説明の際に、次のマイクロアーキテクチャでは、大きなuOPキャッシュを搭載すると予想したが、その通りになった。この予想は、Intelの設計思想からすれば当然の結果だ。ちなみに、AMDのBulldozer(ブルドーザ)でも、似たようなキャッシュを搭載するという噂があったが、実際に搭載したのはIntelの方だった。Bridgeの分岐予測も一新したと説明している。詳細はほとんど公開しておらず、分岐ターゲットのバッファが2倍になったことや、ヒストリバッファがより効率的になったことなどだけが明かされている。ちなみに、IntelはNehalemでは分岐予測ユニットを2階層化した。1段目は小さなコードフットプリントの予測を迅速に行ない、2段目は大きなフットプリントの予測を行なう仕組みとなっていた。して見ると、Intelは依然として、このフロントエンド部分の改良に力を注いでいることがわかる。M(Banias:バニアス)ではMicro-Fusionで、2つのuOPsを1個に統合したまま内部パイプラインで扱えるようにした。MAではマクロフュージョン(Macro-Fusion)を導入して、特定の2命令を1命令に融合させることで、命令フェッチ帯域とuOPs帯域を実質的に増やした。NehalemではuOPsベースのループディテクタで、ループ時にデコードステージをスキップできるようにした。この流れを見る限り、Intelは今後もこの部分に改良を加えて行くことになるだろう。命令フェッチとデコードが重いのは、x86系命令が複雑であるためだ。Intelの強味はx86命令にあるが、そのための負担がCPUのフロントエンドに重くのしかかっている。Intelは強味を保持するために、フロントエンドの改良に継続して力を注いでいる。Traces)」を発表している。PARROTにあるような複雑な仕組みまで行き着くかどうかはわからないが、Intelにはまだフロントエンドの改良の札があることは確かだ。