既報の通り、IDF Fall 2010の基調講演ではSandy Bridgeが大々的に取り上げられた。実際基調講演の後にはIntelのサイトでウェハ(Photo01)やダイ(Photo02)、パッケージ写真(Photo03)が掲載されたし、Technical Sessionではかなり細かな内部アーキテクチャのレベルまで語られた。ということで、まずはSandy Bridgeの内容解説を行ないたいと思う。

Photo01: ダイサイズだが、以前同様に写真から計算してみたところ、21.4mm×10.4mmで、222.6平方mmという計算になった。もっともダイシングの切り代を考えると、20.4mm×9.4mmの191.8平方mm程度という試算も可能で、概ねこの間(多分200平方mmよりちょっと大きいくらい)が実際のダイサイズではないかと思われる。ちなみに有効そうなダイの数を数えると279個となった。

Photo02: ダイの拡大図。この写真からダイの縦横比を計算すると1:2.086というあたりで、21.4mm×10.3mmとかそんな感じだと辻褄が合う計算になる。

Photo03: 実に横長である。Yieldを考えれば、もう少し正方形に近いほうが有利な気もする。

In-Order部

ということでまずレポート1本目ではコアのPipeline構造について御紹介したい。既に塩田氏により、ある程度の解説があるので、これを下敷きに説明を薦めることにする。

Sandy Bridgeは、Fetch→Decode→Alloc/Rename/Retirementを行なうIn-Order部と、Scheduler/Executeを行なうOut-of-Order部に分かれているので、まずはIn-orderのFetch～Decode部(Photo04,05)である。このレベルでは、従来のNehalemとは殆ど変わらない構造となっている。ただこれに加えて、最大1.5K命令分のDecoded μOp Cacheが搭載された(Photo06)。これに伴い、どうも従来のLSD(Loop Stream Detector)は廃された(というか、このDecoded μOps Cacheに統合された)形になるようだ。もともとCore 2/NehalemのLSDは、あくまでも小ループの検出のみを行なう仕組みであり、他の分岐予測機構とは一種独立した形で実装されていたが、Sandy Bridgeではこのループ検出も分岐予測機構の中に組み込まれると同時に、より大きなバッファを持つ事で長大なループあるいは複雑なループに対応できるようになった、という事である。

Photo04: 同時4命令以上をデコード可能、という数字はNehalemと同等。問題はこの"Industry leading branch predictors"。

Photo05: もっとも、MicroFusionやMacroFusionの組み合わせとか制約に関しては、多少なりともNehalem世代から改善されているのではないかとも想像されるが、このあたりは公式なドキュメントが出てみないと何とも言えない。

Photo06: LSDはCore 2で18命令、Nehalemで26μOpsだったから、これに比べると大幅増加である。80%というのは分岐予測機構の数字なのだろう。

その分岐予測機構は今回「ゼロから作り直した」(Photo07)としている。ターゲット数が2倍とかより長大なHistoryに対応といった話は、実はNehalemもSandy BridgeもBTBのサイズとか構造が公開されていないので何とも言えないのだが(非公式な情報としては、L1 BTBが512Entry、L2 BTBが2K Entryという説がある)、まぁこれらは単純に倍になっていると考えてよさそうだ。また、Decode μOp CacheがHitしている間はFetch～Decodeが寝ている(Photo08)というのは、Clock Gatingをもう少し強力に掛けられる、というあたりではないかと想像される。

Photo07: Nehalemの場合はこんな感じ。まぁCore 2のものを多少改善したというレベルである。

Photo08: Nehalemまでは、LSDが効いている間はFetch～DecodeはNop動作(つまりクロックは供給されているが何もしない)だったのが、今度はDecode μOp CacheがHitしている間はFetch～Decode段のClock供給を止める様になったものと想像される。最初は「Nop動作の場合には自動でClock Gatingが効くのでは?」と思ったが、どうもそれだけではなさそうだ。また、Power Gatingを噛ますとなると、ここだけ電源プレーンを分離する必要があり、また退避/復帰に結構な時間が掛かるので性能面へのペナルティも著しいから考えにくい。恐らくはClock Gating＋αというあたりであり、文字通りの電源Offではないと思われる。

続いてはAllocate/Rename/Retirementである。このスライドでは、In-Order側のAllocate/Rename/RetirementとOut-of-Order側のSchedulerが一緒になってしまっているが、とりあえずIn-Order側を考えるとZeroing Idiomsという新機能がある。このZeroing Idioms、春のIDF Beijingでは説明が一切なかったので謎だったが、これがXORなどを使ったレジスタクリアを指す、という話は塩田氏のレポートにあるので繰り返さない。ちなみにこれは、Intelの提供するCode Analyzerをつかって、命令単位で「それがどう実行され、どういうHardware Resourceを消費するか」を分析するためのものである。プレゼンテーションそのものはAVX命令の説明であり、なので例も普通のXORではなくAVXレジスタに対するXORとなるVXORPSとなっている。左端を見れば判るとおりμOpそのものは発行される(だからNum of μOpsが1)にも関わらず、ポート(これは後で説明する)を一つも占有しないあたり、これは実際には命令を発行せず、Retirement Unitだけで処理されると判断できる。