夢とロマンが足りない。(Nehalem予想の当否)   

2008年4月20日



☆心理戦から体力消耗戦へ。   
引っ越しも紆余曲折を経てようやく先が見えてきた。 しかし、荷物運びの運送屋代金をケチって自前で運ぶことにしたので週末は未だ多忙状態だ。 引っ越し作業だが、当サイトの部屋は本とPC系ジャンクが多く、梱包作業で肉体的な疲労が重なってきた。

友人には「おまえの荷物なんて所詮ジャンクPCばっかりだろ。あれを捨てれば段ボール箱もかなり減る。これを機会に捨てたらどうよ?」 なんて言われているのだが、確かに否定はできない状態だ。 しかし、当サイトにとってのジャンクPCとは、ある種のレゾンデートルみたいなもんである。 と言うわけで、今は体力勝負という段階なのだ。

で、その体力はと言うと...実は当サイトの場合は学生時代には意外にも体育会系所属(居合道部)。 PCマニアというとオタク系とか引きこもり系とかネガティブなイメージが大半なんだろうし、 逆に体育会系出身者というとこれまたステレオタイプな見方ではキーボードも指一本でしか入力できないIT音痴というイメージかな?  当サイトは、ある意味ではPCマニアとしてはかなり異端な存在なのだ。

と言うわけで、居合で鍛えた足腰でガンガン引っ越しという目論見 ...だったのだが、体育会系の体力があったのはもはや昔話という事実を思い知らされる結果となった。1) メタボ気味の体に本いっぱいの段ボール箱はかなりきつい。 段ボール箱には大中小と3サイズあるのだが、油断して大サイズに全部本を入れてしまったから、さあ大変。 引っ越し先が木造建築考で床が耐えられるか心配だったので捨てられる本はすべて捨てたけど、 それでも本いっぱいの大サイズ段ボール箱はさすがに腰に来る。 (当サイトからのアドバイス。引っ越しの際には本を入れる段ボール箱は中サイズ以下にするのが、ギックリ腰予防のコツである。)

それでも本はまだ段ボール箱に収まるから良いけれど、46inchのレグザ(液晶テレビ)はどうしようか?  運搬中にパネルをぶつけたら一瞬にして1年間の残業代がパアになってしまう。 液晶パネル面にベニヤ板でも貼って運ぶべきなのかな?

だが、不幸中の幸いと言うべきか今年は仕事かまあまあ順調で、年度末にもかかわらず休日出勤はほとんど無し。 一昨年の「月休2日制」から見れば夢のような状況である。

と言うわけで、2時間だけだがようやくお花見にも行けた。 行ったのは小見川の城山公園である。 ここは山の上なので眺望が良く、関東平野を鹿島工業地帯に向かって一望できる。 今回は本文に写真が無いので、日本人の心のふるさと、桜のお花見写真で癒してくださいませ。

近頃唯一行けた癒しは小見川城山公園のお花見。
城山公園は高台の上にあって眺望がグー。写真の通り鹿島工業地帯などが一望できる。

☆予想的中率0.23%   
と言うわけで未だ暇無し状態が継続中なのであるが、 当サイト的に注目のNehalemの概要が公開されたので感想を書いてみた。

当サイトはNehalemについてはいくつかの予想を書いていて、 SMTの復活とか、オンチップメモリコントローラの採用とか、 GPU混載(これは今回のチップではなく派生品の将来構想だが、intelから発表はされている。)とか、 幸いにして今のところ全部的中している。

そして、これが的中すれば100%全部的中となるのがデカップルド・アーキテクチャ採用説目指せパーフェクト!と言うわけだが、実際はどうだったのであろうか?

Nehalemのアーキテクチャに関しては下記のリンク先が一番詳しいと思われるのでリンクしておく。 リンク先で一番重要なのはLoop Stream Detector(以下LSDと略記)に関する記述なので、興味のある方はご一読いただきたい。

IDFで公開された「Nehalem」の内部アーキテクチャ
IDF Shanghai 2008 - Nehalem情報を総まとめ、コアの内部構造からプラットフォームまで

さて、これを読んで皆様はどう思われたであろうか?

IDFで公開された「Nehalem」の内部アーキテクチャプロセッサコアの内部構造(2)を読むと、 後藤先生も大原先生もトレースキャッシュとフィロソフィは同じと見なしているようだ。 だが質的にはともかく容量面があるので、これをもって「当サイトの予想は100%的中しました。」と勝ち名乗りを上げるのは、 脳天気な当サイトでもちょっとお手盛りが過ぎる気もする。 質的には確かにトレースキャッシュと同じ機能だが、量的にはキャッシュと言うにはあまりにも容量が小さい。 量的にはどう見てもバッファという印象だ。

当サイト的な分析であるが、大原先生の言うとおりこのバッファが質的には事実上のトレースキャッシュである点は間違いないだろう。 理由は簡単で、同記事にもあるとおり単なるバッファならFIFOバッファであるべきところを ファーストループに沿って再実行できる点と、x86ではなくμOPsを保存することでデコードを省略している点から読み取る事ができる。 トレースキャッシュの本質は「デコードと実行をデカップルすること」にあるわけだから、LSDはその条件を満たしている。 (Core MAの構造ではデコードと実行をデカップルできないから、一見似ているが動作の本質は全く異なる。)

しかし、その容量はたったの28μOPsである。 定性的には予想は的中したと言えるが、たった28μOPsではそれは限りなく黒星に近い白星。 キャッシュとしてみた場合の容量を定量的に考えれば、それはあくまで補助的役割と考えざるを得ず、 本質的にデコードの負荷を前後でほぼ完全にデカップルする事を目指した容量ではない。

ちなみに、キャッシュの容量と性能の関係だが、 螺旋階段が性能を上げる。(キャッシュだけに頼れない理由。)で述べたとおり、 キャッシュは容量が少なければ少ないほど容量あたりの性能向上効率は良いハズ。 ミスヒットが多いほど改善率としては高くなるからである。 効率面から見た場合は、意外にも容量は小さければ小さいほどよいのである。 (大容量化すると絶対性能は上がるが、容量あたりの性能向上率は低下する。)

とすると、トレースキャッシュが容量効率面で従来型キャッシュより容量効率が悪い点を勘案すると、 トレースキャッシュ容量はできる限り減らして、その分2次キャッシュ容量を増やした方が (絶対性能は落ちるだろうけど)トランジスタ効率は上がるだろう。 最近の設計トレンドが絶対性能から電力効率へ移行しつつある事を考え合わせると、 この観点から大規模なトレースキャッシュの採用は差し控えられたと思われる。

つまり、トレースキャッシュをアーキテクチャの根幹に添えるのはトランジスタ効率面で避けたけれど、 デコードの負担を完全にデカップルすることはあきらめて、その負荷を一部減らす補助的メカニズムとしてならば28μOPsで十分と判断したものと思われる。

要するに、トレースキャッシュによるデカップルド・アーキテクチャは定性的には採用されたと言えるけれど、 それは骨太な設計思想の根幹と言えるものではなく、あくまで補助的存在なのだ。 当サイトの予想はあくまで骨太な設計思想としてデカップルド・アーキテクチャが復活する事を意味して発言していたので、 胸を張って「的中しました。」と言い切るためにはNet-Burstでの容量からμOPs-Fusionによる容量削減分を差し引いた容量分は必要と言える。 つまり、どんなに小さく見積もっても数K-μOPs程度の容量は必要。 残念ながら、定量的に見た場合はNet-Burstでの容量と今回の容量比分だけの的中率と考えるべきだろうね。

と言うわけで早速計算してみよう。 Net-Burstのトレースキャッシュ容量は12K-μOPsなので、28μOPsをそれで割ると0.23%となる。 と言うわけで、当サイトの最後の予想は完全に間違っていたわけではないけれど、 的中率としては0.23%というトホホな判定となった。

今回の予想の判定は、定性的には予想が的中したが、定量的には的中率0.23%と敗北宣言せざるを得ないものと考えている。 (皆様は定性的判断と定量的判断のどちらを重視しますか?)

と言うわけで、当サイトの予想が当たっているのか外れているのか、 当否にかかわらず検証することを以前お約束していたので感想を書いてみた。 定性的に見れば予想は的中していたが、定量的な部分を考慮すると事実上の敗北宣言という結果となった。 パーフェクトならずして、ちょっと無念。

☆デカップル用バッファという意味での6X86との類似性   
ちなみに、このLSDだけど、昔の6X86プロセッサにちょっと似ている面があると思った。

6X86とは旧Cyrix社製のCPUで、今や憶えている人の方が少ないのかもしれない最後の純CISC-x86プロセッサである。 CISCプロセッサであること以外にもその特徴はいくつかあるが、ユニファイド・キャッシュ型のL1キャッシュであった事が指摘できる。

現代のx86プロセッサは、Crusoe等の一部の例外を除けばすべてが内部RISC構造2)であり、 すべてがハーバード型のL1キャッシュを持つ。 (命令専用キャッシュという意味ではトレースキャッシュもハーバードキャッシュの変種と分類できる。) しかし、6X86はユニファイドキャッシュだったために、キャッシュに関していくつかの長所・短所があった。

長所は少ないデータに複雑な処理の場合とか、多めのデータに単純な処理の場合でも、 データと命令のキャッシュ内での容量の振り分けが自律的に行われること。 ハーバードキャッシュだと、多めのデータに単純な処理の場合は、 命令キャッシュが余っているのにデータキャッシュが不足なんて事態が起こりえる。

短所はデータアクセスと命令アクセスがバッティングした場合に、 どちらかの処理を遅延せざるを得ない事。 ハーバードキャッシュでは命令とデータが区別されているためアクセスのバッティングが生じない。

で、6X86ではユニファイドキャッシュの弱点であるデータアクセスと命令フェッチのバッティングを緩和するために、 ユニファイドキャッシュと命令デコーダーの間に256byteのバッファが挿入されていた。 しかも一番重要なことは、このバッファは単純なFIFOバッファではなくてその中にループ処理があれば命令を再利用する事が可能だったことだ。

つまり、このバッファ内にループ命令が収まれば、ユニファイドキャッシュはデータアクセスに専念できるというわけだ。

これを当サイトの眼で見れば、どう見ても事実上のL1キャッシュなのであるが、 Cyrix社はこれをあくまでバッファと言っていた。 もしキャッシュだと言えば、ライバル企業から「6X86はL1命令キャッシュが256byteしかない。」という ネガキャンを言われかねないためであろう。 (もちろん、これはNehalemも同様である。これをトレースキャッシュと認めれば「たった28μOPsのキャッシュ容量でしかない。」 と言われかねないので、あくまでバッファだとしているのだろう。)

ともあれ、LSDの構造はこの6X86のバッファを彷彿とさせるものである。 6X86はCISCだからバッファ内にあるのはx86命令自体なので NehalemのLSDよりはCore MAの構造に似ているとも言えるが、 問題を起こしやすいユニットとの間に高機能バッファを入れて 問題点をデカップルしようとする根本的な発想は同じであろう。

と、ここで気づいたのだが...  プロセッサ中に問題点があるとき、その問題点を根本的に解決するのが一番の正攻法なのだが、 もしそれが技術的に困難な場合は次善策として問題のある部分をできる限りデカップルするという発想は正しい設計思想であろう。 技術的な現れ方は最新鋭の技術であっても、根本的な設計思想は意外にシンプルな昔ながらの設計思想を再利用するのも効果的なのかもしれない。

☆CPUコア的にはCore MAの改良版だった。   
話は変わるけれど、トレースキャッシュ採用説の当否以上に当サイトが驚いた事がある。 それは、NehalemのアーキテクチャがCPUコア部分だけ見ればCore MA(Penryn)の改良版だったことである。 これには非常に驚いた。

正直に言うと、NehalemのCPUコアは完全に新設計になることは全く疑念の余地のないものとして、 Core MAの改良版であることはまったく考えもしていなかった。正直に言うと1秒だって疑っていなかった。 なぜって、intel自身がチックタックモデルでの抜本的改革の順番だと言っていたし、 設計チームが全く違う上に、同じ社内とは言えオレゴンチームと主導権を争っていたライバルの設計なのだから...

以前、当サイトはPenrynについて「Core〜Core2のアーキテクチャが失敗作というのならば短命に終わるのは当然である。 しかし、失敗作どころかAMDからシェアを奪還した名機なんだから改良の余地がある限り延命策をとるのは経営者として当然の判断だろう。 そしてその間に少しでもNehalemの完成度を上げるべきだ。」と書いた事がある。 当時はNehalemが根本的に新設計であることを全然疑っていなかったのでそう書いたわけだが、 今にして思えばCPUコアに関してはNehalem自身がCore MAの延命策だったのだ。

事実、発表されたブロックダイアグラムを見るに改良版Core MAであることは明白で、 これは事実上のオレゴンの敗北宣言のように思える。 Net-Burstの失敗でいまだに自信を失っている訳でもないのだろうが、もし当サイトがコア部分のアーキテクトなら悔し涙に暮れるところだ。

たしかにコア部分の重要性が相対的に下がってきているのは事実だと思う。 当サイトはPC用途ではシングルスレッド性能を重視する気風だけど、 たとえパターソン教授のグラフを見ていなかったとしても改善ペースが鈍っているのは認めざるを得ない。

ILPウォール...その通りである。だからPC用CPUはバカげたことに対応ソフトも無いのにマルチコアに走った。
メモリウォール...その通りである。だから流体等のHPC分野でスカラ機はベクトル機の数分の1程度の低い効率でしか動かない。
パワーウォール...その通りである。だからハイパーパイプライン構造のNet-Burstは失敗した。


パターソン先生の意見には当サイトもまったく異論はない。

また、当サイトはメモリのバンド幅やレイテンシの重要性も認識している立場なので、 オンチップメモリコントローラの採用は以前から大賛成の立場だ。 (「Nehalemでの搭載はむしろ遅きに失した感さえある。」という主張をどこかで見た記憶があるが、当サイトもまったく同感である。) そして、GPU混載という当サイトの主張も最初は多方面からバカにされたが今ではAMDもintelもその方向に向かっている。

だから、アンコアと呼ばれるCPUコア以外の部分に設計リソースを割くのは、 研究開発費や人材投入の投資効率から見た場合は確かに正しい選択と言えるかもしれない。 (いや、当サイトがもし半導体メーカーの技術責任者だったら、 経営責任としてそういう方向性の判断をせざるをえない気がする。)

NehalemはPC用途だけではなく、サーバー用途とかHPC用途とか、今までのCore MAが苦手にしてきた分野も 主戦場として睨まなくてはならない宿命を背負っている。 投入コストに見合う性能を得ようとしたら、スケーラビリティー向上とかSIMD強化とかメモリのバンド幅・レイテンシ改善とかが優先されるのは 論理的に見て正しい判断で、消去法でCPUコア内部の抜本的改革が主戦場から外されるのはやむなきの感もあるのだ。 (PC用途だからシングルコアの性能が要求されるのであって、サーバー用途ならマルチコアでもかまわないし、HPC用途ならばSIMD強化とメモリのバンド幅強化は重要だ。)

☆性能は良くても、「夢とロマン」が足りない。   
しかし...

それはわかってはいても、CPUコアの根本的な設計思想ってのはアーキテクトのプライドと信念の現れのような気がするのだ。 その設計思想が正しいかどうかを別とすれば、AMD64系ならば正統派高IPC主義、Net-Burstならば高クロック主義、 Crusoeならばホットスポットの動的最適化という、いわばアーキテクトの主張がコアそのものからにじみ出ている。

CPUマニアにとってのCPUコアとは、フランス料理で言ったらバター、イタリア料理で言ったらトマト。 CPUマニアとしてはまさにここがキモであって、これがダメなら他がいくら良くてもダメという部分なのである。 CPUコアは、まさにCPUの「コア」であって、アーキテクトの主張...というか、 アーキテクトが目指す理想のアーキテクチャに対する夢とロマンがにじみ出ていないとね。

_| ̄|◯ というわけで、Nehalemの当サイト的な評点はちょっと下がった。 コア内部の抜本的な刷新が無かったのが当サイト的ながっかり感を増幅しているのである。

Nehalemの設計思想はCore MA、Net-Burst、Fusion、AMD64のいわば「いいとこ取り」であって、独自の設計思想が薄いと思う。 具体的に言うと、コアはCore MAの改良版、それにNet-BurstからSMTとデカップルドアーキテクチャを利用(ただし、これはオレゴン自身に由来する設計だけど。)、 GPU混載はFusionの後追い、オンチップメモリコントローラはAMD64の後追い... 技術的にはこの選択は決して悪いものではなく、性能面での評価はまったく下がっていないが、あまりにも開発リスク回避的な印象があるのだ。

依然としてPC用途ではシングルスレッド性能が重要なことには変わりがないわけだし、 「ILPウオールがあるからこそアーキテクトの腕の見せ所。」と考えるのはロマン派過ぎますかね?

まぁ、当サイトも三流とはいえ一応は研究開発部門所属なんでビジネスの厳しさはよく理解しているつもりである。 各種ウォールがあるなら正面突破を試みるよりも投資効率のよい分野に開発の主眼を移すのは正しいビジネス感覚だし、 「夢とロマンではメシは食えない。」と言われれば確かにその通り。

なので、今回の話はマニアの戯れ言として読み流してくださいな。 コア自身の革新が改良レベルに留まった以上はPC用途での性能向上も改良レベルと思うのが正しい推測だと思われる。 だが、サーバー用途やHPC用途など、PC用途以外の分野でのシェア獲得も狙っているとするならば、 事業としてはNehalemの方向性は間違ってませんから...

当サイトの感想としてはNehalemのアーキテクチャに技術的にケチを付けるつもりはほとんど無いけれど、 一つだけ物足りなさを感じるとすれば、それはハードウエア的な根幹設計部分があまりにも他プロセッサのいいとこ取り的でリスク回避指向が強過ぎることである。 要するにNehalem最大の問題点とは夢とロマンが足りず、ワクワク感に欠けることなのだ。



1)
居合いは「居合い腰」と言って、上級者になるほど腕から腰に重点が移るものとされている。 「腕で切るな、肩で切れ。肩で切るな、腰で切れ。」とも言われる。 当サイトのような初心者と練達の士との一番の違いは「手の内」と「腰使い」にある。

ちなみに、最近はもう全然稽古していないから、抜打とかやったら床打ちしそう。 やっぱ鍛錬は日々やらないと意味がないね。 (床打ちとは、居技での暫撃の際に手首の締めが甘く、切っ先が床直前で寸止めできずに床板に当たって傷を付けてしまうこと。 稽古中にこれをやらかすと音で簡単にバレてしまうので、とても恥ずかしい思いをする。)

2)
intelはCore MAの事を「もはや内部RISCプロセッサではない。」と主張しているが、 μOPs-FusionによりNet-BurstよりはCISC寄りであるものの、x86を直接実行せず固定長命令のμOPsを実行する以上は内部RISCプロセッサの一種であろう。