CPUのリストラ(スパコンに似てきた?)   

2005年6月12日



☆名を捨てて実を取る大人の判断。   
4月、5月は一般公開の当たり月であるため、3回連続で一般公開見聞録を書いた。 このため、4月10日の話の続きがほったらかしになっていた。 ようやくの続きである。

だが、その間にいろいろ新たな情報が入ってきた。

例えば前回の続きに関連する内容で言うと2点ある。 一つはCELLのSPEが公式には7つになったこと。 8つの内1つは歩留り低下防止のための予備ユニットという事らしい。 もう一つは、CELLの倍精度浮動小数点演算性能が4GHz時に26GFLOPSと単精度に比べて 大幅に落ちる事が公開されたこと。

当サイトの感想を言わせていただくと、どちらもまったく妥当な判断であろうと思う。

まず、第一に公式なSPE数を7つに減らした事についてだが、 当サイトの指摘としてCELLではバンド幅の関係でSPE8個の性能をすべて引き出すことは難しい点を指摘した。 (CELLの相対評価と絶対評価をご参照ください。) 用途によっても事情は異なるが、よほどCELLの中身に習熟したスキルの高いプログラマでない限り、 おそらく8個のSPEの能力を完全に引き出すことは難しいと思われる。

通常はXDRのバンド幅の関係でSPE8個でも7個でも性能に大きな違いは出ないと言うのが実態だろう。 稼働SPEユニット数が増えるに従って、性能向上は急速に飽和していくハズだからである。 SPE1個と2個ではほぼまるまる2倍性能が違うだろうが、7個と8個ではXDRのバスが詰まってしまって 誤差範囲の性能向上しかない場合が多いと思う。(アプリ次第ではあるけれど...)

ならば、公式なSPE数を1個減らしても、実質的な性能低下はほとんど発生しない理屈であり、 その分歩留りを向上した方が経費削減になる。 もし、SPE数に比例してリアルに性能が向上するならば、公式なSPE数を7つにしてしまうと (PPE分を除けば)性能が7/8に低下してしまうハズだが、おそらくそうはならないだろう。 SPEを1個減らしても実質的ダメージはこれよりずっと少ないハズである。

従って、ゲーム機はコスト削減が至上命題であるため、この判断は全く妥当であると考える。 最初の発表では「実を捨てて名を取る。」形のカタログ性能至上主義であったが、 今回の発表は「名を捨てて実を取る。」形であり、好感が持てる。

また、倍精度浮動小数点演算性能が4GHz時に26GFLOPSであったことも、ゲームと 科学技術計算の本質について深い理解の上での正しい判断の結果だろうと思う。

実は同じ浮動小数点演算ベースとは言っても、必要精度はゲームと科学技術計算では大きく異なる。 ゲームでは物理シミュレーションとはいっても、本物「らしく」見えれば正しく正確に物理モデルを 再現している必要はないと思われる。だから、科学技術計算のように厳密に有効桁数にこだわる必要はない。

しかし、科学技術計算では単精度で事足りる問題は比較的希で、 ほとんどが倍精度(場合によってはそれ以上)の精度が要求される。

データ量と演算量の関係も異なる場合が多い。 パソコンの場合、ゲームではキャッシュが良く効くとは言い尽くされた言葉である。 しかし、科学技術計算ではキャッシュが効きにくいというのもその筋のプロの間では常識である。

この違いは何を意味するのだろうか?  当サイトではSPEすべての性能を引き出すことが難しいことをバンド幅の面から指摘したが、 その困難性の程度はアプリによっても様々に変わる事が重要だ。

キャッシュとLSは異なるシステムではあるが、 LSでもキャッシュでも局所性を利用している点で同じであるという事に注目すべきであると思う。 つまり、ゲームではCELLのLSが上手く機能し科学技術計算ではLSには収まりきらない事を意味すると考えられる。

この2つを組み合わせて考えるとどうなるのだろう?  XDRのバンド幅不足が、単精度演算中心のゲームでは致命傷にならず、 倍精度演算中心の科学技術計算では致命傷になりうるという事だろう。

とすると、倍精度演算性能を単精度演算性能並に高くしても、 XDRのバンド幅が不足して倍精度時の実効性能はほとんど向上しない事になる。 おそらく倍精度演算性能が26GFLOPSではなく単精度と同じ256GFLOPSであったとしても、 効率が無様に低下するだけで惨めな結果に終わっただろうと予想する。

だとすれば、倍精度演算時の性能向上には手を抜いて、その分のトランジスタをLS容量の向上なり、 XDRのバンド幅向上なりに注いだ方が正しい判断という事になる。 (たぶん、実際にそうなっているであろう。) 当サイトがXDRの性能から予想した科学技術計算時の実効性能は6.4GFLOPSである。 SPE8個分の256GFLOPSはピーキーすぎると指摘したわけだが、約1/10の性能の26GFLOPSならそれなりにバランスが 取れていると言える訳であり、ここで手を抜くのはよく理解できる。

倍精度時の演算性能が単精度時の1/10であったことに対して失望感を抱く人が多いかもしれない。 しかし、当サイトの判断は逆で、無駄にトランジスタをつぎ込んでピーク性能向上を行っても 実効性能はあまり向上しない、という事を熟知した上での大人の判断の様に思えるのだ。

☆ILPを捨て、DLPとTLPにすがる。   
上記のCELLについての新事実がすべてバンド幅がらみと判断しているのは我田引水ではないつもりである。 前回からの内容の続きになるわけだが、バンド幅と演算量の関係は今後のCPUの性格を規定すると予想している。

さて、前編では今後のCPU開発では、CPU内部の非演算ユニットのリストラが必要との考え方を示した。 このCPUのリストラを行うために考えられる方法には何があるだろうか?

過去のソフトウエア資産を継承するためにILPに走ったのであるから、 (x86系では大決断になるが)もしこれを捨て去ることが出来ればまだ手はあると思う。 というか、それが大前提だろう。 (ただし幸いなことに、TLPの場合性能向上が無いだけで、過去のソフトでも一応動く。)

大雑把には3つあると思う。 一つめは回路の簡素化による高クロック化、二つめはDLPの利用、 3つめはTLPの利用だ。

非x86系CPUの代表としてCELLで考えてみよう。 まずCELLは回路の簡素化による高クロック化をやった。1) 高クロック化は誰でも思いつく単純な方法だが、 スレッド数に関わりなく高速化できる点には捨てがたい味がある。

高クロック化は過去のソフト資産を継承しつつ高速化できる方法であるため Pentium4でも非常に力が入れられている方法だ。 ただしPentium4では複雑な回路構成のまま高速化したので非演算ユニットのリストラは出来ず、 消費電力もバカ高くなってしまった。

CELLではクロック周波数はスタートでいきなり4GHzに達し、 実搭載品では3.2GHzまで下がるが、実験室内では5.6GHzも実現済みと聞く。 ただし、トランジスタ効率を下げないという前提があるから、 Pentium4の様な複雑怪奇な方法ではなく、徹底的に回路を単純化するという 手法で達成しているとアーキテクトのインタビュー記事に書いてあった。 Pentium4での失敗経験に学んだ正しい認識だと思うが、絶対性能はその分落ちているハズである。

DLPに関してはSPEがSIMDメインに設計されている事で、 非常に重要視されている事がわかる。 x86では各種演算ユニットの中の一つという位置付けである SIMDユニットであるが、SPEではメインの大黒柱である。

TLP利用の充実についてはSPEが8個も搭載されている事が如実に示している。 CELLはTLPを何よりも重視する設計であろう。

で、隅に追いやられているのがILPだ。 SPEでは2命令同時実行でしかなく、しかもインオーダー実行という 古い形式をあえて採用している。 たとえばAMD64では、継続的に3命令をこなせる命令帯域を持っており、 また、アウトオブオーダー実行により、(瞬間最大風速だが) 9命令を同時実行できる。CELLのILP水準は初代Pentium世代と同じであり、 設計思想的には10年以上も先祖返りしたことになる。

もちろん、これは設計思想が後退したのではなく、あえてそうしたのだろう。 強いILPはCELLには不要というきっぱり割り切った判断だ。

余談だが、当サイトもSPEに強いILPは向かないと考えており、 実はSPEの中身は、命令長のそれほど長くないVLIW構成ではないかと予想していた。 (ちなみに、PPEの様な用途では強いILPを残すべきと考えている。)

VeryLongではなくて少しLong(笑)な2〜3命令並列位のVLIWである。 2〜3命令というのは、スーパースカラの並列性抽出能力が平均3命令程度であることから 推定したものであり、Itanium系でも並列性は3命令パックがベースになっている。 ゲーム機では過去のソフト資産継承を考えなくて良い(昔のチップをI/O用兼用として 入れておけばいいから。)ので、x86とは違ってVLIWのデメリットは無いからである。

実際のSPEを見て分かるとおり、この予想は結局間違っていたので「書かなくて良かったぁ〜」という感じだ。 後講釈になるので少し後ろめたいのだが、おそらくVLIWにすると命令のコードサイズが(NOPとかが増えるため) 大きめになるので、ただでさえ逼迫しがちなLS容量が圧迫されるのを防ぐ意味でインオーダーのスーパースカラを 選択したのでは無いだろうか?

ともあれ、CELLではx86で主流であったILPを捨て去り、代わってDLPとTLPにすがる事で 非演算ユニットの比率を下げ、トランジスタ効率を高める設計思想に転換したわけだ。 (そして、その結果回路が簡素になり高クロック化もできた。)

☆IPCからバンド幅への転換。スパコンと同じ制約が...   
この設計思想の転換はSPEの総演算能力256GFLOPSという値に如実に表れているとおり、 一応の成功を収めている。「一応」と書いたのは、それが常用可能な性能か、 それともピーキーで使いにくい性能かという点で、 当サイトと製造メーカで判断が異なるためである。

SONY-IBM-東芝連合が言うとおりピーキーではなく使いやすいという主張が 本物であれば、CELLは歴史的転換を成し遂げたCPUとして コンピュータの歴史に残るであろう。 だが、ゲームのような効きの良い用途では爆速だろうが 汎用としては問題があり、すべてが爆速にはならないだろうと 当サイトは考えている。

その理由は、CELLの絶対評価と相対評価で述べたとおりである。 理論ピーク性能に対してメモリバンド幅が絶対的に不足している と考えるからである。

DLPとTLP優先の設計思想により、CELLはトランジスタ当たりの演算効率を 劇的に上げることが出来た。 だが、浮動小数点演算がベースである限り、データ供給が間に合わなければ やはりストールしてしまう。 また、DMAがLSにデータを供給している最中に併行して演算が出来なければ、 それもまるまるSPEがストールしている事と同じ事である。

CELLのLSはキャッシュと異なりコヒーレンシー維持の負担が無いのはメリットだが、 容量が256KBしかないのが最大の弱点だと思う。

では、容量をもっと増やせばいいのかというと、LS自体は キャッシュと同じくなんの演算もしないユニットであるから、 トランジスタ効率を上げているつもりで、他のユニットが削られる事による 性能低下がメリットを相殺してしまうという問題がある。1つのSPE内での LS容量が256KBなのは、おそらく主用途(ゲーム)を考えた上でのトータルバランスで決定された 最適容量なのであろう。 2)

つまり、メモリバンド幅不足による効率低下を抑制する方法としては、 (当たり前のことではあるが)メモバンド幅を強化するのがもっとも効果的 であろう。

ただし、CELLの場合はSPEユニットはダイ内で増減できても、 メモリバンド幅は簡単には増減できない。 (正確に言うと、減らすことはもちろん簡単であり、 増やすことが簡単には出来ないわけだが。)

理由は2つあると思う。

一つはメモリのバンド幅改善はコスト増に直結すること。 ゲーム機は価格に対する要求が非常にシビアであるから、わかってはいても 「ではバンド幅を増やしましょう。」とは簡単にはできない事情がある。 予算的に限られたバンド幅をギリギリまで使いこなす事で回避しなければならないのは、 ゲーム機のやむを得ない宿命であろう。 (XDRデュアルは、価格的制約の中では頑張っている方である。)

もう一つは、SPEユニットの増減は純粋にダイ内部の問題であるが、 メモリバンド幅の増減はCPUパッケージの ピン数の問題やダイの端子数問題に引っかかるからである。

CELLではXDRが採用されているが、これはパラレル方式とはいえ ピン1本あたりの伝送レートが非常に高い"準シリアル的"な 広帯域メモリバスである。 その本質は、いかに少ないピン数で高いデータレートを実現するかにあり、 CPUパッケージのピン数制約の中で最大限メモリバンド幅を高めるかに 非常に役立っていると考えている。

CELLはメモリの他にチップ間接続インターフェイスを装備しているから、 ピン数の制約はx86系CPUよりさらにシビアであろう。 このため、CELLがメインメモリにGDDR3ではなくXDRを採用したのはまさに正解だと思う。 (何度も繰り返すが、SPEを増やして内部演算能力を高めることは簡単だが、 メモリバンド幅は簡単には増やせない。)

ベクトル型のスパコンでもバンド幅の限界の一つがメモリユニットへのコネクタの山だったり、 CPUパッケージのピン数(ダイの端子数問題も含む。)だったりすると考えている。 コンシューマの半導体もようやくその世界に入ってきたと言うことだろうか?

そうなると、CELLの問題をx86に当てはめて類推した場合、 いったい何が起こると予想されるのであろうか?

x86では内部のコア数を増やす検討が行われている。 これは、非演算ユニットをリストラする訳ではないが、演算ユニットと非演算ユニットの比率を ある世代の比率で食い止めて、これ以上非演算ユニットの比率が増える事を阻止する意味がある。

そうなれば、CELLと同じ問題に直面する事は容易に想像できて、 バンド幅向上が内部演算性能向上に追いつかない事態が発生すると考えられる。 つまりこれがintel言うところの「feed the beast」という奴なのだろう。

もちろん、x86ではコスト的制約がゲーム機程ではないし、 CELLと異なりチップ間接続インターフェイスのPIN数を確保する必要性も薄いから、 実際に直ちにこれが制約事項になる訳ではないだろう。

しかし、全般のトレンドは動かしようもなく、 今後のCPU開発の制約事項としてバンド幅不足の問題、 そしてそれに付随するメモリユニットへの接続問題やパッケージのピン数問題が浮上するのでは無かろうか。

もちろん、設計サイドではこの問題に気づいているハズであり、 CELLの場合はXDRデュアルという選択は現状でベストを尽くした対策であると思う。 (XDRはピン数が比較的少なく、また、コストが厳しいはずのゲーム機としてはかなりコストがかけてある。)

しかし、この旺盛な食欲を満たすために現状最適な選択肢としてXDR(しかもデュアル) という精鋭があてがわれたが、それをもってしてもゴジラに立ち向かう 自衛隊よろしく、防戦一方というのが実情ではなかろうか?

というわけで、やはりマルチコア化の行き着く先に見える最大の障害は バンド幅とパッケージの制約であろうと考える。 メモリユニットへの接続問題を考えれば、intelがFSBをシリアル化しようとしているのはもっともだと思う。 CELLからx86を見ると、今後のx86では「パッケージ問題」とか「ピン数問題」とか 「メモリのシリアル化問題」という言葉がキーワードになるような気がする。 おそらく数年後のPC誌にはこのような用語が頻繁に現れるのではないだろうか?

☆マニアの戯言?   
余談だが、マルチコア化のもう一方の弊害としてキャッシュコヒーレンシーの問題があるという指摘がある。 キャッシュベースアーキテクチャにおいて多数のコアを集積化すると、キャッシュコヒーレンシーが維持できなくなるという指摘だ。 (DOS/V POWER REPORT誌 2005/7号P139の記事等をご参照ください。)

このため、例えば上記の雑誌記事では、バーチャルマシン技術を駆使したCPUコアのパーティショニングについて言及されていた。 しかし、この方法は確かに多数のアプリが同時に動く場合は効果的だろうが、 単一アプリの高速化については問題の解消になりにくいと思う。 (そして、PCでは単一アプリの高速化がサーバー用途に比べてより重要である。)

これについて一言だけ当サイトの考え方を言っておくと、 見解は以前述べた通りで「ベクトルプロセッサが良いですよ。」 という以前からの指摘通りである。 バンド幅の問題についてはベクトルプロセッサも同様の問題点を抱えるわけだが、 キャッシュコヒーレンシーに関しては事情が異なるからだ。

それはなぜか?

ベクトルプロセッサでキャッシュコヒーレンシーの問題が発生するかどうか、 お考えいただければ簡単にわかることである。 そもそも、原則としてベクトルプロセッサにはキャッシュが無い。(笑)

また、キャッシュの効きが悪いマルチメディア系処理においてキャッシュ容量に大きなダイ面積を割く マルチコアはトランジスタ効率が相対的に悪くなる気がする。 キャッシュ面積が必要なのは従来型アプリの部分である場合が多いから、 それは高ILP型のコア部分のみ充実させれば十分なのではないだろうか?

当サイトの主張であるベクトルプロセッサオンチップ構成だが、x86では全然相手にもされていない。 だが、Xbox360の構成は結構似ている。

当サイトのベクトルプロセッサオンチップx86という主張は、 Xbox360のCPUコアを3つから高ILPコア1つに減らし、Unified-Shader型GPUをさらに汎用化してCPUと統合したものに近い。 つまり、ワンチップ化されたx86版Xbox360様な構成をお考えいただければわかりやすいと思う。 (実際ブロックダイアグラムを見ると、Xbox360ではGPUがノースブリッジとしての機能を兼ねており、 UMA構成のPCアーキテクチャをゲーム機に移植したような感じである。)

シングルスレッド性能が要求されるx86では、最低一つは大きな高いILPを持つCPUコアを入れなければならない。 しかし、最近の流れであるマルチメディア系処理では高ILP設計思想は非効率だ。 (だから、デュアルコアがマルチメディア系処理で高性能を示すとは言っても、根本的問題解決になっていない気がする。)

この矛盾に対する対策としては世間の流れはTLP重視のさらなるマルチコア化の進展である。 だが、当サイトの主張であるヘテロコアによるDLP重視もかなり有力な気がする。 エンコード等の用途では最新のデュアルコアCPUをかなり上回る性能を発揮するハズである。3)

プロの方々がお昼休みにお弁当を食べながら当サイトの記事を読んでいるとしたら 思わずご飯を吹き出してしまうのかもしれない。だが、当サイトは真剣である。

☆余談:週末の花見(花菖蒲編)   
今回の内容は写真が全然無いので少し寂しい。 というわけで、今週末に花見に行った 佐原・水生植物園 と潮来・前川あやめ園の写真を掲載しておく事にした。 桜が終わっても花見のネタはあると言うことである。

例年ならこの時期には満開であるハズだが、今年は異常気象故に7〜10日ほど開花は遅れているそうだ。 現状では3〜4部咲きなので、来週末頃に満開になると思われる。来週末か再来週末が見頃であろう。 (だが、3〜4部咲きでも十分きれい。)

佐原水生植物園の花菖蒲
あやめ祭りではあるが、実際は花菖蒲。見ての通りまだ3〜4部咲きである。

花見は好きだが、あやめ、花菖蒲、かきつばたの厳密な定義とかは、この水生植物園の説明で 初めて知った。また、品種がこんなに多いということも初めて知った。

花菖蒲には江戸系・肥後系・伊勢系という3つの系統があるそうで、 世界で栽培されている観賞用花菖蒲の源流は日本なんだそうだ。 (最近は海外でも愛好者が増えて、逆輸入される品種も多いそうだ。)

江戸時代に花菖蒲の栽培が許されてたのは武士などの特権階級だけだったそうである。 今日では多くの愛好家に楽しまれており、花見だけではなく 品種改良もアマチュアの楽しみの一つらしい。 軽い気持ちで花見に行ったのだが、花菖蒲の世界も奥が深いねえ。



佐原水生植物園では品種毎に分類して栽培されている。
一番右が黄色色素遺伝子を取り入れて作られた「愛知の輝」(まだあまり咲いてないですけど。)

花菖蒲は江戸時代に品種改良が進んで、多様な色や形や模様が開発されたが、 花菖蒲には黄色色素が無いため江戸時代には黄色の花だけは出来なかったそうである。 そこで、近縁種から黄色色素遺伝子を導入して初めて作られた黄色の花が、この「愛知の輝」だそうである。 (ごく最近まで青いバラが作れなかったのと同じだね。)

花菖蒲には多くの愛好家がいらっしゃるので、詳細は愛好家のWebサイトを検索して頂きたい。 見飽きないですよ。

潮来・前川あやめ園の花菖蒲

前川あやめ園は水生植物園と異なり品種毎に分類して栽培されている訳ではないので、 色々な花が咲き乱れる様子を楽しむことが出来る。 愛好家には品種別の方が楽しみやすいのだろうが、シロウトの当サイトにはこちらの乱れ咲きも楽しい。

まぁ、いつもシロウトのくせに偉そうな大言壮語している当サイトだけに、 時にはこういう解毒作用のある癒しも必要であろうね。



1)
余談だが、PCマニアは非常に高クロック化にシビアなのであるが、 ことCELLに関しては4GHz(PS3実機では3.2GHz)という高クロックに全く批判が出ないのは何故だろうか? (Net-Burstに関しては、あれほどボロクソに言われているのに...)

もちろん、Net-Burstとは異なりクロックの割には消費電力は思ったほどは増えていない。 しかし、それならば批判されるべきは高クロックではなく高消費電力であろう。

ちなみに、当サイトは以前から「絶対性能を考える場合は、高クロック化も 一つの選択である。」とPCマニアとしては異端の主張をしてきた立場なので、 CELLの4GHzクロックを批判するつもりは無いのだが...

2)
科学技術計算ではキャッシュは効きにくいわけだが、もし仮にそれなりに効くとしたらどうだろう?  その場合は、おそらくLS容量をもう少し増やせばベストなワークステーションになると思われる。 キャッシュが効きにくいとは言っても程度問題であり、 気象用途のように箸にも棒にもという場合から、MDの様にそれなりには効くという場合もある。

3)
同様な効果をもたらすものとして、高性能シングルコアCPU+ハイエンドGPUという 構成も考えられるわけだが... バスを経由しての2チップでメモリ空間も分離という部分が チップ間の協調性・即応性の点でボトルネックになる様な気がする。 バスが詰まりにくいという点では逆に良いのかもしれないが...