老舗うなぎ屋の秘伝のたれ!?(Sandy BridgeのμOPキャッシュ)   

2010年9月26日



☆クラウド化がシステムの軽量化とはまるで意味不明。   
忙しい毎日が続いているので、いつもの余談もネタ無し。 特に今月末は年度末への中間期に該当する9月末なので、進捗管理も含めて本業の仕事量も大変。 ご感想メールを読むに、余談ネタを楽しみにしている方も意外に多いようなのだが、申し訳ありません。

というわけで、前回のネタであるスパコンの話の続きを簡単に。 表題が「クラウドの時代になぜスパコンだけが...   」 になっている。これを読んで、「おぉ、このサイトはついに意見を変えたのか?」 と思った方も多いと思う。クラウドはスパコンとの比較に対して、 巨大戦艦化とは逆方向の理念として語られる場合が多いからだ。

しかし、当サイトの主張は巨大戦艦化こそ重要であるという内容。 表題を読んだときに想像される内容と書き込まれた内容が真逆の意見であることに違和感を感じた方も多いはずだ。

じつはこれがまさに当サイトの狙い所。 一見真逆の方向性に書いて違和感を感じさせることで、 内容の主張点を明確化させるという文章記載法の一つである。

それにしても、世の中にはクラウド化がシステムの軽量化だと思っている人がなぜこんなに多いんでしょうね?  クラウドはその名の通りユーザーサイドからはシステムが見えにくくなる。 一人一人の個別ユーザーから見ればシステムの効率化が軽量化につながる場合も多い。 その意味では確かに軽量化ではあるとは思う。

けれど、システムの管理運用サイドに視点を変えてみて欲しい。 ユーザー側から管理者・運営者側に視点を変えると見方が全然変わってくるからだ。 そのデータセンターが軽量な小規模システムと考える人は誰もいないだろう。 クラウド化...それはシステム全体として考えた場合はまさに巨大戦艦化以外の何者でもないはずである。

クラウド需要が伸びれば伸びるほどクラウドを支えるデータセンターは巨大化する。 当サイトの予想には自信がないものから絶対の自信を誇るものまでいくつか段階があるが、 クラウドが巨大戦艦化する傾向にあるという予想には絶対レベルに近いかなり強い自信がある。

☆1世代遅れての予想的中(Sandy BridgeのμOPキャッシュ)   
今回は仕事の忙しさもあって、本格的にその詳細が発表されたSandy Bridgeの簡単な感想でお茶濁し。 ちなみに、上記の予想と違って下記の予想の自信度はそれほど高くないので、 今回の話はマニアの戯れ言レベル。その筋のプロから見たらお笑い話かもしれないが、その点はご容赦を。 (ま、そのときはお笑いサイトでの週末の息抜きだと思ってお読みください。)

というわけで本題へ。 当サイトにとってSandy Bridgeは一つの時代が終わり新たな時代が始まる事を意味するプロセッサである。 それは、当サイトの以前からの主張、つまり「PC用途で単純なマルチコア化を進めてもアプリの対応が進まない限りほとんど意味はない。 従って、現状のアプリ対応状況ではGPU混載こそが王道である。」 という主張に沿った初のプロセッサだからである。

当サイトは2004年にGPU混載の主張を開始して以降、この主張を飽きるほど何度も繰り返し主張してきた。 そして、掲載初期にはマルチコアの否定もGPU混載もPCマニアからの同意は全く得られなかった。 マルチコア否定論はPCマニアから次々と反論メールを頂いたし、 GPU混載主張に至っては最初の掲載年である2004年の最大不人気記事として年末のワーストコラムに認定せざるを得なかった位である。 (ただし、ワースト認定なのは最大不人気だからであって、当サイトは内容の間違いを一切認めずに論戦継続を宣言。)

しかし、AMDのATI買収が当サイトにとっての逆転満塁ホームランとなり、 これ以降GPU混載批判メールは1通も来なくなった。 初志貫徹して意見を曲げなかったことが功を奏したのだ。

従って、Sandy Bridgeのどのバージョンが売れるかは、当サイトの予測能力を占うまさに試金石となる。 GPU混載版がバカ売れし、8コア版は(サーバー用途では売れるだろうが)PC用途では全く売れないというのが当サイトの予想。 マルチコア化の進行が正しければGPUを混載しない8コア版が売れ、 当サイトの主張が正しればGPU混載のデュアルコア版が最多販売量となるハズだ。 つまり、マルチコア化が正しい方向性なのか、GPU混載が正しい方向性なのか、 論戦に最終決着を付ける決勝戦が始まろうとしている。 従って、両者のPC需要での販売量には大いにご注目いただきたい。 (たとえ当サイトの意見が間違っていて8コア版がPC用途でバカ売れしたとしても、検証記事を書くことをお約束しておきますので。)

ところで、今回の発表でGPU混載の件以上の注目点が一つあった。 それはμOPキャッシュの採用である。

μOPキャッシュ、つまり内部RISCアーキテクチャにおける内部命令をキャッシュすることでデコード系の負荷を低減し、 x86系CPUにおける最大のボトルネックを解消する技術。 Net-Burstの失敗によりNet-Burst系のテクノロジはPCマニア間ですべて完全否定されてきたが、 全てが失敗なのではなくトレースキャッシュの概念は決して見下してはならないという主張もまた、 当サイトがご批判を受けながら見解を曲げずに何度も何度も主張してきた技術なのだ。 (最初はintelによる復活説を主張してきたわけだが、この予想があまり当たらないのでトレースキャッシュAMD採用説を掲載したこともある。 こちらの予想も思いきり外れたけれど...)

しかし、Sandy Bridgeではここが完全にキャッシュとなって当サイトの予想がようやく的中した形になった。 過ちと認めずにトレースキャッシュ復活説を掲載し続けたことが、GPU混載説同様にここでもようやく功を奏したのであった。 (ただし、Sandy Bridgeでの話としては書いていなかった事が唯一最大の反省点。 今にして思えば、笑われようが何しようが徹底的にしつこく繰り返し書くべきだったね。トホホ。)

ちなみに、前段階のNehalemでは28μOPsだった。このため、あまりに容量が小さいので 「これはバッファであって、キャッシュではない。」という当サイトへの批判記事がブログに掲載されたこともある。 これに対しては、当サイトは前段階の28μOPsがバッファかキャッシュかという批判に対して文句を言うつもりはさらさら無い。 (よくある中傷メールではなく、見解の相違はあっても真っ当なご意見だから。) ただ、intelの技術者が基本構想の理想として最初からキャッシュを目指していた事は、今回の事実をもってご理解いただけると思う。

Sandy BridgeのCPUコアはゼロから再設計された新アーキテクチャではなくNehalemの改良版であるのだから、 μOPキャッシュはNehalemの基本構想の延長線上にあると考えるのが妥当。 Nehalemで扱う命令数が少なかったのは費用対効果における確証が得られない事に対するリスクヘッジと、 ダイ面積対効果の非効率性が当時の技術水準では解消しきれなかったためと考えている。

というわけで、当時Nehalemの技術予想に対して当サイトは過去のコラムでまとめ記事を書いていた。 当サイトのNehalemに対する予想項目は下記の4つ。

このうち、トレースキャッシュ復活説以外は完全に的中したので、点数としては75点。 満点ではないが、PCマニアレベルとしては及第点であった。 そして今回、Sandy BridgeのμOPキャッシュ採用で、トレースキャッシュ採用説が1世代遅れて的中したわけだ。

当サイトはAMDのFusion構想に敬意を表してGPU混載プロセッサとしてはFusion系を買うことを過去に宣言していたわけだけど、 当サイトの主張点であるトレースキャッシュ構想の正しさを事実を持って証明していただいたことにも少々恩を感じている。 これは購入判断がAMDの圧勝から、かなりの接戦になった感じ... というわけで発売開始になったらSandy Bridgeを買うかZacate系にするか、かなりの悩み所だ。 (ただ、当サイトは以前この記事でSandy Bridgeは売れると予想したので、 1個だけとはいえ自分で売り上げを増やすのは反則技かもね。)

☆Sandy Bridgeの「秘伝のたれ」は分岐予測技術にあるとする意見には賛成。   
というわけで、μOPキャッシュについて簡単に考えてみたわけだが、 Nehalemで28μOPsしか無かったのに、なぜ1.5K-μOPsへと大容量化できたのかが正直よくわからない。 効果面で寄与が大きいだろう事はいろいろ書けるのだけれど...

これについては、後藤先生の記事に非常におもしろい記事が書かれていた。 なぜSandy Bridgeはそんなにパフォーマンスが高いのかという記事と トリックを重ねたSandy Bridgeマイクロアーキテクチャ という記事 がそれである。

当サイトは、物事の状況を把握するのに会見で何が発表されたかよりも何が発表されなかったかに 注目することが重要だと言うことを、先進国首脳会議の会議内容をスクープした凄腕新聞記者から学んだ事がある。 その意見に従って、上記の記事を読むとおもしろいことがわかる。 Sandy Bridgeでは分岐予測に関する新技術がいくつか投入されているにもかかわらず、 本来強烈なアピールポイントになるべきμOPに対する分岐予測の発表があまりなされていないようなのだ。 (一部に分岐予測の話は書かれているが、分岐予測の圧縮が核心部分とは正直思えない。)

これは、分岐予測技術にintelの大変重要な隠し味が含まれている事を意味しているように思える。 先の記事でも「いずれにせよ、分岐をどう巧妙にハンドルするかが、キャッシュのカギになることは確かだ。」 との記載があるが、当サイトもこの発言は事の本質を見事に突いている見解だと思う。 そして、自己都合解釈のように思われるかもしれないが、上記のμOPキャッシュに対するコア技術が この分岐予測に対する新技術のように思われてならないのである。

つまり、Nehalemでトレースキャッシュ容量が28μOPsしか無かったのは、 分岐予測に対するこのレベルでの実用的かつ効果的な技術が未発達段階だったのに対し、 今回のSandy Bridgeではこの部分にうまい方法が開発されたので容量を増やして実用化できたのだとも思える。 (個人的には、μOPキャッシュは通常キャッシュよりもアーキテクチャ内部に大きく食い込んでいるため、 ヒットしなかった場合のペナルティーが大きいだろう事が難しさを増しているように想像している。 だから、ヒット率の向上はもちろん重要だけれど、それ以上に ミスヒット時のペナルティーをいかに減らせるかや、ヒット率を高める工夫によってパイプライン段数が増えてしまうといった 相殺効果をいかに減らすかが核心部分なのではないだろうか?)

要するにずいぶん以前からトレースキャッシュ系の技術を扱ってきたintelにとって、 このあたりのノウハウ蓄積は老舗うなぎ屋の「秘伝のたれ」みたいなもので、 失敗経験も含めてNet-Burstでの経験が生かされているのだろう。 だから、過去にトレースキャッシュの使用実績がない他社がいきなり大容量品を実用化しようとしても難しいのだと思う。

実際、同記事ではμOPキャッシュのヒット率が高い事を掲げて「サイズの割に効率が良いキャッシュ」と説明している。 逆に、当サイトは以前、トレースキャッシュの数少ない弱点に関して、「ダイサイズの割に効率が低いキャッシュである。」事を 推測していた。(このコラムをご参照ください。) これは、当サイトの予測が元々間違っていたという可能性もゼロではないが、 Net-Burstでは12K-μOPsのトレースキャッシュが通常型キャッシュで8KB〜16KB換算というのがintelの公式発表値であるから、 この非効率性とSandy Bridgeでの性能を比較すれば当サイトの見解はおそらく間違いではない。 (μOPの1語は非常にbit数が大きいだろうから、容量あたりのトランジスタ数は非常に多いはずである。 つまり、トレースキャッシュは単位ダイ面積あたりの性能向上率という意味では非常に脆い側面を持つというのが過去の当サイトの予想。)

μOPキャッシュには、デコード部の低消費電力化・低発熱化、デコード能力のボトルネック解消、 デコードユニットと実行ユニットで系統の違う命令を同時に扱える等々、メリットは数え切れない位ある。 だから、数少ないデメリット部分が「秘伝のたれ」によって解消されれば大容量化に踏み切るのはむしろ当然であるように思える。

また、Turbo Boostの上限値を決める最大要因はデコード系の発熱だろうから、 μOPキャッシュにより命令デコーダーの稼働率が減って熱密度が低下すれば、Turbo Boostの効き具合も大きく改善できる理屈になる。 PC用CPUではシングルスレッド性能が第一に重要なのであるから、「3つのウォール」によってシングルスレッド性能を高められなくなっている現在、 数少ないシングルスレッド性能向上方法であるTurbo Boostの効き具合が良くなる事は重要ポイントであろう。 従って、ここからSandy BridgeではTurbo Boostが従来よりもかなり強化される事が予想できる。

まとめると、Sandy BridgeでμOPキャッシュが採用されたのは、 トランジスタ効率が低いトレースキャッシュの欠点が解消された事によるものと当サイトは考えている。 本来μOPsをなるべく分解しないCore系のアーキテクチャは、バラバラに分解するNet-Burst系よりもトレースキャッシュに適しているというのが 当サイトの以前からの主張であった。だが、実際には実機装備までに当サイトの想定以上の時間がかかっており、 調整がかなり難しい分野だったように想像している。

その状況下で、分岐予測技術におけるintelの「秘伝のたれ」により容量効率が低いというトレースキャッシュ系の弱点が解消される事で ヒット率が向上し消費電力増大が抑制されて、その結果28μOPsから1.5K-μOPsへと一気に大容量化できたのだろう。

Sandy BridgeでμOPキャッシュが採用されたのは分岐予測技術との合わせ技1本であると当サイトでは予想している。 この分岐予測技術に関して当サイトでも良いアイディアを思いついたら予想を書いてみたいが、 脳みその容量不足と仕事の忙しさのため現段階では妄想レベルでしか思いつかない。1) この部分は「intel秘伝のたれ」なので、老舗うなぎ屋の秘伝のたれ同様に (特許化された場合を例外として)おそらく公開されることは無いと思う。

ともあれ、intelはSandy Bridgeの普及に自信を持っているように見受けられるが、 これは以前のマルチコア化のような虚構ではない。 しっかりした下地に基づいた自信の表れと当サイトには思える。 以前当サイトが主張した「Sandy Bridgeは売れる。」という予想を曲げる必要性は、 今のところ全く無さそうだ。


1)
ただ、単純に分岐予測のヒット率を上げることだけではなく、 ミスヒットした場合のデメリットが少ない分岐予測機構(やや矛盾した表現だけど)に秘密がありそうだ。 たとえば、ループ中で分岐命令を予測ミスしてトレースから外れたときに、どの分岐命令でミスする可能性が一番高いかが事前にわかっていれば、 次のトレースを事前にデコードしてμOPキャッシュ投入し予備調整しておくことでリカバリータイムを最小限に抑える事ができるはずだ。 そんな分岐予測ミス対応プリフェッチみたいなメカニズムとかは考えられないだろうか? 

要するに、通常のキャッシュとは違ってμOPキャッシュを使えば、実行ユニットとデコードユニットが全然別の命令を扱っていても問題が生じない。 ブロック間の運用の自由度が増えることはμOPキャッシュ最大の強みであると思われ、この強みを生かさない手はないと思う。 これをマルチスレッドの他スレッドに対応させることも当サイトはもちろん以前書いているが、 同一スレッドであってもループ処理を実行中にループ終了条件を推定して分岐予測ミスに備えるというCrusoe的な対応だってあり得るだろう。 通常のキャッシュは命令の初回実行では効果が無く2回目のヒットから効果が出るのが教科書的基本原理だけど、 予測技術と組み合わせる事で予測ミスのペナルティーを最小限に抑える事でうまく対応しているのでは無かろうか?(ただし、まだ妄想段階ですけど。)