それでもNet-Burstは死なず!(大穴万馬券狙い編)   

2007年5月13日



☆今年のGW帰省   
さてさて、当サイトはもともと個人的なメール代わりの近況報告サイトの性格を起源として持つので、 本ネタに入る前に余談を書いている。これは盲腸みたいなものなのだが、意外にも友人には好評。 硬派なお堅いネタの息苦しさを和らげる効果があるからだろうか?

と言うわけで、今回の余談はGWの帰省。 2年前、十石峠を通ってGW渋滞を避けながら帰省した事を 一般公開見聞録(臼田宇宙空間観測所編)に書いた。 で、「十石峠は国道と言いながら、メチャメチャに悪路だった。」という話を会社でしていたら、 長野県が実家という方に「十石峠は国道だからそっちにしたんだろうけど、ぶどう峠の方が道も景色もいいよ。」 と教えていただいた。と言うわけで、今回の下道ぶらぶら帰省は秩父経由、ぶどう峠越えで GW渋滞を避ける事にした。

成田から所沢経由で国道299号を進む。飯能市を超えると山道になるが、新緑の季節は本当に気分良く走れるね。 すっきりさわやかに走って朝8時頃に秩父に到着したが、秩父ではすでに芝桜渋滞が始まりかけていた、 渋滞するのも道理で、2年前に一度行ったので今回はパスしたが秩父の芝桜はとてもお勧めだ。

国道299号を進んで志賀坂峠を越えたところで偶然おもしろい物を見つけた。 前回は気づかずに素通りしてしまったのだが...恐竜の足跡の化石だそうな。

恐竜の足跡の化石
足跡は矢印の2個と枠内に多数あります。右図は枠内の拡大写真。

この岩は漣(さざなみ)岩と呼ばれているのだが、 左上の2つの穴状の跡が大型恐竜のもので、左下から右上に向かって列になっているのが、 小型恐竜の群れが走った跡らしい。 ここは白亜紀には河口の砂浜だったそうで、その上に恐竜の足跡が残ったんだそうだ。

さて、恐竜の足跡を見学したところで先へ進む事にする。 道沿いの神流川には太公望がずらりと釣り竿を並べている。 鮎の解禁はまだ先だろうけど、イワナ狙いだろうか?  この季節、春風も吹いて気分良く釣りが楽しめるんだろうね。

道の駅・上野の少し先に十石峠とぶどう峠の分岐点がある。 今年はここを左折してぶどう峠へ...

白樺林と渓流が美しいが、ご老体には少々きつい急勾配のぶどう峠越え。
十石峠と違って気分良く走れる。車の行き違いもごく一部以外では問題なし。
ぶどう峠では周囲を遠望できる。(右図)ただし、道は途中からかなりの急勾配。(中央)

ぶどう峠はしばらくは渓流の脇を通って走る。新緑の渓流が美しい。(写真左) 道も国道である十石峠よりずっと良くて、ほとんどの部分で車の行き違いが可能。 そして、しばらく行くと写真の通り急に急傾斜のつづら折りが現れた。(写真中央) ここから先は新緑もまだまだこれからという感じであり、頂上のぶどう峠が近い証拠だろう。

走行16万kmを優に超えたご老体・愛車プリメーラカミノのアクセルに鞭を入れて、 この急勾配をグイグイ登っていく。 う〜ん、飛ばしている訳ではないのに、かなりアクセルを踏み込んでるね。 急勾配&NAエンジンで空気の薄い高所&ご老体と悪条件がそろってはチト苦しい展開か... こら〜、根性見せないと新車に買い換えてしまうぞ〜。

しばらく行くと頂上であるぶどう峠に到着した。 日航機墜落事故のあった御巣鷹山の近くである。 ここは交通量も少なくて、行き違いはバイク2台と車1台のみ。 GWとは言っても渋滞とは無縁だ。 余談だが、ぶどう峠は漢字で書くと武道峠という硬派な名前なんだね。 葡萄峠かな?と思っていたんだが...

ぶどう峠の先、長野側はずっと緩斜面だ。長野側からなら峠という感じではないだろう。 佐久の標高がかなり高い証拠だ。ここから、松原湖高原線を通って去年は行けなかった麦草峠を目指す。 (今回は万一に備えてチェーン持参である。)

松原湖高原線から望む八ヶ岳方面(左図)と、雪景色の麦草峠近傍。(右図)
長野らしいすばらしい風景が続く。しかし、頂上の麦草峠付近は雪景色。 危ない危ない。

麦草峠近くまで登ってくると、周囲は雪景色だ。 一昨年は路面凍結注意の看板を見て引き返したのだが、 日陰には残雪も一部残り、ノーマルタイヤでは危険な状態である。 速度を落とし慎重に運転。 これなら確かにGWといえどスタッドレス装備が必須だろう。

頂上を少し諏訪側に行き過ぎると展望台がある。 諏訪湖を越えての遠望だからアルプスの姿は少々遠いが、 南アルプスから中央アルプスを遠望できるとても景色の良い場所で、駐車場も整備されているのでお勧めだ。 晴れていればすばらしい高原気分を堪能できる。 と言うわけで、奥蓼科の高原気分(別荘地帯でGW中は意外に人口密度高し。)を堪能して帰ってきた。

☆妙な苦情。   
と言うわけで本題に入る。 さて、今回は久々に少々波乱を含んだ話題にしてみた。

というのも、当サイトのご愛読者にして会社仲間から、 「最近CPUネタが減ってきた。仕事は暇になってきたのに、ちょっと弛んでるじゃない?」 という苦情(半分ジョーク)を頂いたからだ。 もっと本来のネタで物議を醸せという、ある意味で不謹慎な要望でもある。(こらこら〜。)

と言うわけで、今回は久々に物議を醸し出す問題児ネタで行ってみたい。 勇み足、大いに結構というわけだ。

さて、当サイトのネタで過去に物議を醸したといえば、何と言っても Net-Burstは死なず。(Meromのアーキテクチャ予想) だろう。 このネタは相当に叩かれたし、結果としてはMeromの予想としても間違っていた。 本人も予想の間違いは認めて、その原因を分析した内容も ふやけた解凍済み命令(CPUマニアのぼやき編) に出している。

では、なぜまたもこの題名なのか?

単なるセンセーショナリズムでも、意固地になっている訳でもないつもりである。 今回の分析は大穴万馬券狙いではあるが、的中しているかどうかは別として 一応話の筋道が通っている事はお読みいただければおわかりいただけると思う。

今回は巷でPentium PRO以来の大変革と呼ばれるNehalemの実体について考えてみたい。

☆Nehalemコアの革新はあるのか?   
Nehalemについては一部で既に報道がある。 当サイトも で書いた通り、その革新部分は大雑把に以下の3つだ。

  1. Hyper-Threadingの復活
  2. オンチップメモリコントローラ
  3. CPU-GPU混載
しかし、これには肝心の改良がすっぽりと抜け落ちている。 それはCPUコア自身の革新だ。

NehalemはPenrynの後継チップだが、そこには大きな設計思想の変革があるらしい。 報道 によると、Meromから見た場合Penrynの改良は「美容整形」程度の部分的なものであり、 Nehalemでは心臓外科に相当する抜本的改革が行われるそうだ。 これはintelのEden氏自身の口から出た言葉であるから、 (彼が嘘をついていない限り)全くの真実と考えるべきだろう。

Penrynでは小改良しか行われなかった理由はチックタックモデルから来る制約だそうだが、 これは当サイトも納得できる理由説明だ。

以前、当サイトも「キャッシュ増量とILP向上はセットであり、 お互いに無関係に一方を強化し続けるだけで一方的に性能を強化できる訳ではないと思う。 基本的には両者は同時に改良すべきだし、それが不可能ならばせめて世代毎に交互に改良してゆくべきだ。」と 原因があって結果がある。(PenrynとNehalem雑感)で書いた。

ここで「それが不可能ならばせめて世代毎に交互に...」と書いたのはチックタックモデルを念頭にしたもので、 プロセスルールの刷新とアーキテクチャの抜本的改革を同時にやろうとすると、 トラブルが発生したときにどちらが原因なのかわからなくなって現場が大混乱になる。 従って、リスクマネジメントのためには小改良と大改良が交互に来るのはこの世界ではやむを得ない。 (というか、この世界以外でも製造業なら当然のことである。 新ラインでないと新製品が作れない場合は例外だが、製品の抜本的改革と製造ラインの抜本的改革を同時に行わないのは、 製造業のリスクマネジメントにおける基本だ。)

しかし、Nehalemでは抜本的なアーキテクチャ革新の順番となる。 Hyper-Threadingの復活が抜本的改革とは言えないから、 CPUの根本的設計思想に何らかの新たな思想が付け加わるハズであるが、 その思想とは何だろうか?

これを考える上ではMerom、Penrynの問題点を考える事が一番の近道だろう。 MeromからPenrynへの改良では美容整形的な小改良は済ませているそうだから、 Nehalemで成される改良は心臓外科に相当する抜本的なものだ。 ちなみに、美容整形なる小改良は実行ユニット関連のものであり、当サイトは以前デコード系以外にも 実行ユニット系にも問題ありと指摘したこともある。

つまり、当サイトの指摘事項に関してはPenrynである程度手が付けられたわけである。 この段階でCoreマイクロアーキテクチャの中で心臓外科に相当する問題点と言えば、 プロの記事でなくても 誰でもデコード系の問題を指摘するのではないだろうか?

当サイトもそう思う。 Nehalemで行われる抜本的改革とは、おそらくデコード系の抜本的改革だろう。

☆デコードの制限を取り払うデカップルド・アーキテクチャ   
Coreマイクロアーキテクチャのデコード系はP6アーキテクチャからの古い流れを 引き継いでいる方式だ。つまり、すべての命令をデコードできるロングデコーダーを 一つ搭載し、簡単にデコードできる命令のみを扱うショートデコーダを複数組み合わせるという設計思想である。 単純な命令は出現頻度が高い場合が多いから、デコードしやすい命令が続けば フルデコーダー4つより少ないトランジスタ数でも それほど性能を落とさずに並列デコードを行うことができる。

しかし、問題点もいくつかある。

例えば、ロングデコーダーでしか扱えない複雑な命令が連続すると、 デコード効率が極端に落ちてしまう。 また、命令フェッチ帯域とのバランスの問題もある。 (この辺は当サイトのつたない文章でいちいち書くよりも この辺りの記事 に詳しいので、そちらをご参照ください。)

また、並列度を上げようとするとデコーダーの数を増やさなければならないため、 コア中のホットスポットが拡大してしまい、クロック周波数向上の足かせになる。 さらに、64bitでも性能を落とさないようにしようとするとその悩みはさらに増す。 フェッチ帯域をさらに必要とするからだ。

では、これらの問題点を解消する抜本改革の正体は何なのだろうか?

例えばAMD64系ではフルデコーダー3つ相当という手法で ILP水準3並列レベルのデコードを行っている。 この方法は最も手堅い方法で、消費電力が増えるとか、 クロックが上げにくいとかの問題点はあるが、 基本に忠実な方法と言えるだろう。

ただし、ILP水準4並列を狙ったCoreマイクロアーキテクチャでその手法を取るのは、せっかくの 消費電力面での優位性が揺らぐ危険性があり、またせっかく45nmプロセスルールでAMDより進捗状況が進んでいるのに、 ここがボトルネックになってクロック周波数でのアドバンテージ奪取に失敗する可能性がある。プロセスルールで優位なintelとしては採用しにくい設計思想ではないだろうか?

と言うわけで、当サイトが考えるデコード系の刷新とは、 デカップルド・アーキテクチャの採用だ。

デカップルド・アーキテクチャとはデコード系と実行系をトレースキャッシュで 分離(デカップル)するアーキテクチャのことであり、 x86系ではNet-Burstアーキテクチャがまさにそれだ。

デカップルド・アーキテクチャの特徴はトレースキャッシュにヒットする限りは デコードと実行を分離できると言う点である。 もちろん、通常のアーキテクチャでもデコーダーと実行ユニットの間にはバッファがあるので ある程度の命令ならデカップル可能だが、その作動範囲はトレースキャッシュよりも格段に低いハズである。 (そもそもOut-of-Orderが機能する範囲をカバーできればいいという発想だから、根本的な設計思想からして違う。)

つまり、トレースキャッシュにヒットする分、デコードに時間がかかっても 全体の処理時間の遅れにつながらないし、また、デコーダーが動作するのはトレースキャッシュミス時だけなので消費電力も削減される。

Net-Burstは消費電力問題で大失敗したのでデカップルド・アーキテクチャが 低消費電力と主張しても信じていただけないとは思うが、 実はエネルギー爆食型アーキテクチャとして悪名高いNet-Burstアーキテクチャも、 この部分だけを取り出して考えれば低消費電力的であろう。

設計思想はアーキテクトの思想信条に関わるのでそれぞれ一言あるとは思うが、 もし当サイトがNehalemを設計する立場であったならば、 デコード系がボトルネックと気づいた時点で間違いなくデカップルド・アーキテクチャを採用するだろう。

☆トレースキャッシュはNet-BurstよりもむしろCoreマイクロアーキテクチャになじむ。   
さて、このデカップルド・アーキテクチャであるが、 Net-Burstではハイパーパイプラインの弱点を補強するために採用された。 Net-Burstのパイプライン段数は非常に大きくて、Northwoodでは20段、 Prescotteでは30段に達する。 ただでさえ、これほどの高パイプライン段数なのだ。

もしここで、Net-Burstがデカップルド・アーキテクチャを採用せず、 通常のデコーダー構造を採用していたとしたらどうなるだろうか?  この場合は上記のパイプライン段数にデコーダーの段数が加わることとなり、 分岐予測ミスが発生したときにとてつもなく大きなペナルティが発生する。 また、デコーダーが常時動作しなければならないことで、タダでさえ大きい 消費電力がさらに拡大する。

つまり、Net-burstはハイパーパイプラインが特徴とよく言われるけれど、 これでもまだ通常のアーキテクチャに比べればパイプライン段数を 抑制している方なのである。

と言うわけで、Net-Burstでデカップルド・アーキテクチャが採用された 最大の理由は、ハイパーパイプラインのデメリットを少しでも抑制するためであろう。 Net-Burstではまず高クロック主義が設計思想の中心にあり、 それを実現するためハイパーパイプライン構造を採用し、 そのデメリットを少しでも緩和するためにデカップルド・アーキテクチャを採用した... というのが当サイトの読み筋である

では次世代のNehalemでは高クロック主義は採用されるだろうか?

当サイトの答えはPenrynよりは高クロック志向となるがNet-Burstほどではない という少々ファジーな回答だ。 当サイトはCoreマイクロアーキテクチャの欠点の一つに、 高クロックに対応しにくいという点を挙げたいと思う。 これはPenrynではかなり改善されてきたとはいえ、 デコーダー部分がホットスポットになって全体のクロック向上余地を抑制して しまうためCoreマイクロアーキテクチャでは本質的と考えられる。 (余談だが、Penrynでクロック周波数がそれなりに高くなるのは、アーキテクチャの改善効果ではなく プロセスルールの改善効果がほとんど。)

おそらくNehalemではその点が改良されるはずで、 Net-Burstほどではないにせよ、ある程度の高クロック主義が復活すると予想する。

しかし、その程度の高クロック主義ならば、わざわざ失敗したアーキテクチャを 復活させる必要は無いのではないか...と思われるだろう。 それはその通りである。

実は、当サイトがNehalemでトレースキャッシュの復活を予想するのには別の理由がある。 一つは以前Net-Burstは死なず。(Meromのアーキテクチャ予想) で主張した通り、デコーダーの消費電力を削減し、高クロック動作を容易にする点。 そして、もう一つがμOPs-Fusionとのマッチングの良さだ。

基本的な設計思想を高クロック主義からμOPs-Fusionに置き換えてみよう。 基本的な設計思想が変わってしまうわけだが、 デカップルド・アーキテクチャはμOPs-Fusionに対して有効に機能するだろうか?

Nehalemのパイプライン段数はNet-Burst(Prescott)ほどではないはずだから、 ハイパーパイプラインのデメリット解消という意味での有効性はたしかにあまり期待できないだろう。

しかし、μOPs-Fusionを強化してデコード系が複雑化しても、この部分の影響をデカップルできるために 分岐予測ミスの影響が通常のアーキテクチャより少ないというメリットがある。 また、デコードフェッチ帯域や64bit命令セットのデコードにおいても、 デコーダーの影響がキャッシュヒット率の陰に隠れて表にはあらわに出てこないというメリットがある。

デカップルドアーキテクチャは、キャッシュ前段のパイプライン段数に関しては トレースキャッシュにヒットする限りは影響を受けないので、 ここを強化してもデメリットが少ない。 つまり、デコーダーが複雑化する事による影響を最小限に止めることができると当サイトでは考えている。

また、デコーダーが動作するのはキャッシュミス時だけなので、デコーダーを複雑化しても 消費電力が比例して増えるわけではないというメリットがある。

そして、以前 ふやけた解凍済み命令(CPUマニアのぼやき編) においてトレースキャッシュの問題点をキャッシュ効率が低いことだと書いたが、 μOPs-Fusionを設計思想の中心にするならば、そのデメリットを 最小限に抑制する事ができると思う。

Net-Burstではx86命令をバラバラのμOPsに細かく分解した。 これにより一つのμOPsの処理内容を単純化し、 高クロックを達成しやすくしているわけだ。 だが、これはキャッシュ効率が大きく低下してしまうというデメリットがある。 なぜならば、x86では1命令をキャッシュすればいい場合でも、 分解数分だけ複数のμOPsをキャッシュしなければならないからだ。

では、μOPs-Fusionならばどうだろうか?

以前、Prescott発表前夜(短所の補強編)の中の 「☆μOPs-FusionはNet-Burstアーキテクチャと相性がいいハズ。」という項目 で書いたことだが、μOPs-Fusionで複数の命令を1つに統合できているならば、 キャッシュ効率の低下を最小限に抑制することができるだろう。

Net-Burstでキャッシュ効率が悪いのは、1つのx86命令をキャッシュするのに タダでさえbit数の多いμOPsを、しかも分解数によっては 複数を一時記憶しなければならないためである。 事実、intelはトレースキャッシュのヒット率をx86命令を直接キャッシュする場合に換算して8KB〜16KB相当と公表している。 トレースキャッシュは通常アーキテクチャでは一次命令キャッシュに相当するわけで、 性能全体に対する寄与は2次キャッシュよりずっと大きい。 12K-μOPsのトレースキャッシュはダイ面積換算ではそれなりに大きな面積を喰っているわけで、 それでAMD64系の1/4〜1/8換算の容量にしかならないのでは勝負にならないと思う。

しかし、μOPsへの分解数がx86命令数とそれほど違わなければ、 キャッシュ効率は低下しにくいし、さらにμOPsがFusionされて 複数のx86命令が統合できればさらに効率が上がるだろう。 トレースキャッシュはμOPs-Fusionと組み合わせれば弱点を大きく補強できるわけである。

また、高並列デコードの問題も解消しやすいだろう。 なぜならば、ロングデコーダー4つ相当のデコードは、デカップルド・アーキテクチャでは トレースキャッシュのバンド幅を拡張するだけで実現可能だからだ。 (もちろんそれ以降のパイプラインは4本必要なわけだが、これは従来アーキテクチャでも根本的には同じ。)

これは、ロングデコーダーとシンプルデコーダーを組み合わせる方法では実現が難しい。 (トレースキャッシュ方式ならμOPsは固定長だから、命令長の長さによってフェッチ帯域が不足したり、 逆にムダになったりするという問題が発生しない。)

つまり、トレースキャッシュはμOPs-Fusionと相性が良いと当サイトでは考えている。

高クロック主義達成のためのデカップルド・アーキテクチャではなく、 μOPs-Fusionを含む複雑かつ実質的に高並列なデコードを行うための デカップルド・アーキテクチャ。 そう考えれば、当サイトがNehalemの技術予想を 「それでもNet-Burstは死なず!」と書いた理由がおわかりいただけると思う。

Net-Burst失敗の要因は決して高クロック主義ではないと思う。 高クロック主義でも正しく設計すればPower6のように優れたプロセッサを設計することは十分に可能だ。

では、Net-Burstは何故失敗したかというと、上記のとおり高クロックを実現する手法として、 安易にパイプライン段数を増やし、また、安易にx86命令をバラバラに分解したから であるというのが当サイトの今回の主張だ。 つまり、その2点さえ回避すればトレースキャッシュも高クロック主義も復活する...というのが今回の当サイトの予想である。

そしてCoreマイクロアーキテクチャ最大の弱点であるデコード系の問題点を、 デカップルド・アーキテクチャなら解消する事が十分に可能だろう。 そして、ここが大事なところだが、その解消具合は32bitよりもむしろ64bitで強調される事になるだろう。

☆それでもNet-Burstは死なず!   
さて、当サイトはFusionの一件で評価の乱高下を体験した。 だれにも賛同を得られない笑いもの状態から、AMDのATI買収の一件以降は 読者から予想的中の賞賛を受けた。 これほどの評価の乱高下を体験すると、少々の事では動じなくなる。

内容が内容だけに、今回はさすがにおそらくご賛同者はほとんどいないものと思われる。 しかし、以前完全にダメ出しを喰った Net-Burstは死なず。(Meromのアーキテクチャ予想) の一件はMeromでは外れてしまったわけだが、今回 的中すれば当サイトの以前の予想は数世代先を先読みしていたことになる。 なので、今回は大穴馬券に賭けて、二匹目のドジョウならぬ二匹目のFusionの狙い。 「夢よ、もう一度!」という訳だ。 (勝率は低いとは言え、当たれば万馬券だね。)

正直に言えば今回の予想に関しては自分でも的中率がそれほど高いとは思わない。 何故かと言えば、それはCoreマイクロアーキテクチャが今のところ成功しているからだ。 成功しているなら、それをあえて突き崩す様な手法は取らない方がリスクが小さい。 変えなければならないところは変える必要があるが、変える必要はない所は変えないのも設計思想の一つだ。 フェッチ帯域の問題にしても、64bitの問題にしても、 現在のアーキテクチャを維持したまま帯域を2倍に増やす方法で妥協した方がリスクは少ないだろう。 また、Nehalemの大幅改変も、メモリコントローラ内蔵やGPU混載自体を大幅改変と言えば、 従来のintelアーキテクチャから見ればすでに大幅改変となっている。

が、それは覚悟の上である。 自分の考えでは現時点ではこの方法がベストだと思っているから今回の内容をアップしてみたわけだ。 大ハズレにせよ、逆転ホームランにせよ、Nehalemアーキテクチャの詳細が発表された際には このネタで検証記事を書くことをお約束しておきたい。

ところで、会社仲間者様。これだけの物議ネタを書いたんだから、 さすがに弛んではいないと思っていただけますでしょうか? (「そんなくだらない事言っていないで、さっさと仕事しろ〜。」って言われそうだが...)

もっとも、弛んでいるから「たるさん」なんだという、真実を突いた俗説もあるけどね。