最適なCPUがベストではないという難しい世界。   

2010年2月8日



☆山梨で絶景露天風呂を楽しむ。   
まずはいつもの余談から。

先日、用事があって山梨(甲府)に行くことになった。 で、用件が終わってプライベートタイムになったので、温泉にでも行こうかと思っていた。 山梨には以前から行きたいと思っていた温泉があるからである。 それはここ、ほったらかし温泉。 露天からの絶景がすばらしい超人気温泉である。

ところが、ほったらかし温泉は目的地からさらに北側で、しかもかなり山の上。 なので、ノーマルタイヤの愛車では危険かもしれないとのこと。 温暖な静岡県に出向中なので愛車にはブリザック(スタッドレスタイヤ)が装着されていないうえに、 本来山梨県は豪雪地帯ではないが運悪く数日前に雪が降ったあとだったのだ。

う〜ん、どうしたものか...

と思っていたら、近くにほったらかし温泉に肩を並べる絶景露天風呂温泉があるとの地元民情報。 話に聞いたのはここ、みたまの湯という温泉である。 場所的にはほったらかし温泉よりもずっと目的地に近いところにあるので足取りも軽いし、意見通りこちらに変更。

絶景がすばらしい「みたまの湯」温泉
超有名な「ほったらかし温泉」にも引けを取らないとのこと。

市街には雪は全然残っていなかったのだが、山を登って温泉にたどり着いてみると日陰の路肩には残雪が。 ここでこれなら、ノーマルタイヤでほったらかし温泉は確かに厳しそうだ。

で...噂の絶景はと言うと...

天気が雪雲気味で薄曇りだったのだけれど、それでも下記の通りのすばらしい眺望だった。 露天温泉からは甲府盆地や周囲の山々を一望できる。 これで快晴だったり夜景だったりしたら、もう最高のハズである。 ほったらかし温泉にはまだ行ってないので優劣は付けられないが、 ほったらかし温泉が噂通りの絶景だとしても、これならそうそう後れを取ることはあるまい。

この写真以上のすばらしい眺望が露天や内湯からも楽しめた。
露天温泉内にカメラは持ち込めないので、駐車場からの撮影。

(観光目的で山梨に来たわけではないのでLUMIXを忘れてしまった。昔のしょぼいデジカメで画質悪くてすみません。)

観光で山梨に行ったわけではないので、LUMIX(デジカメ)を持っていかなかったのは大失敗。 車の中に放置されていた古いデジカメでごまかしながらの写真ですんません。

だが、温泉は露天のみならず内湯からも絶景が楽しめるように眺望第一に設計されていて、当サイト的評価では弱点なし。 唯一の問題点は、たどり着くまでの道がわかりにくいことと、あまりの絶景なので客が殺到して大混雑していること位である。 (当サイト自身が、その激混みの原因の一人なわけだが...)

また、かすかなモール臭のある温泉らしい黒湯で、泉質的にも満足だった。 鉄分由来の黒色ではなく、これは100万年ほど古代に堆積した植物からの有機成分によるものだそうだ。 以前、千葉県成田市近くに住んでいたときに紹介した 大和の湯と同じ泉質だね。

いやいや、今まで山梨県は帰省の折に通ることは多かったが、寄り道する機会は少なかった。 でも、観光で行くにも穴場的なところも多くて、結構良いところだね。 次回機会があれば、時間の関係で食べられなかった山梨名物「ほうとう」を是非食べてみたいところだ。

☆当サイトの予想はどこまで的中していたか?   
さて、今回はスパコンネタである。 仕分け作業の件によりこの国家事業は一般国民の目線に触れることになったが、それは事業の進め方の話がメイン。 当サイトもここでコラムを書いて意見表明したけれど、 PCマニアとしては本来意図したテーマではない。 と言うわけで、今回はPCマニアとしてあくまで趣味の話に戻って次世代スパコンそのものの中身について 楽しみながら眺めてみることとした。

次世代スパコンは現在では富士通案で統一された状況になっているわけだけど、 当サイトは以前富士通案についてハードウエアの予想をしたことがある。 (この記事の富士通案予想部分をご参照ください。) なので、まずは予想が的中したかどうかを見てみよう。 当サイトの予想と、その当否を下記に一覧表にしてみた。

予想項目 当サイトの予想 実機での状況 当否 備考
CPUのアーキテクチャ シンプルなスカラかVLIW SPARCアーキテクチャ × 富士通の看板プロセッサであるSPARCアーキテクチャベース。
CPUのクロック 意図的に抑制する 2GHz ライバルであるPower7の半分。チップあたりの性能がPower7に比べて半分になるが、1FLOPあたりの電力効率は約1.7倍になる。
CPUのコア数 マルチコアの強化 8コア 予想通り。
コア内でのデータ並列性の利用 SIMDを超強化 1コアでSIMD2命令の並列実行が可能。 的中かと思っていたが、当サイトの考え以上にSIMDを超強化した構想もあったので△とした。
レジスタ数 出来うる限り増やす。 32個から256個へ拡張。 予想通り。
メモリコントローラ CPUと同じコアに集積 オンチップメモリコントローラ 予想通り。
ローカリティーの利用 ローカルメモリの方が良いが過去との整合性でやむなくキャッシュを採用。 セクタキャッシュ 当サイト指摘の問題点をキャッシュのまま解消した発展的な解決方法。
キャッシュ容量 オンチップメモリコントローラに任せる形で容量を抑制する。 1次命令・データ各32KB+2次5MB Power7はeDRAM搭載で3次キャッシュまで含めれば32MB搭載。
ネットワークコントローラ CPUと同じコアに集積 コントロールチップは別コア × こちらのチップは現段階では未公開のようだ。
ネットワークトポロジ 2D or 3Dメッシュ 6次元トーラス 6次元だが、これは故障対応を見越しての2重化によるもので、実際は3次元相当。また、メッシュとトーラスは端がつながっているかどうかだけの違いで、基本は同じなので○とした。

チップに関しての予想はそこそこ当たっていると思う。 ただし、オンチップメモリコントローラの採用とかマルチコア化なんてのは予想の難易度がかなり低いから、 的中したとは言っても自慢できる項目ばかりではないけれどね。

ネットワークについては現段階では情報公開が少ないので、 現段階でわかったのはトポロジの予想が的中したと言うことだけ。 なので、全情報が公開された時点で別途検証してみることにしたい。

当サイトではこれについて共有メモリというかなり特徴的な予想(と言うか、当サイトからの提案)をしていた。 マルチコア化とかの難易度の低い予想と違って、こちらはかなり踏み込んだ当サイトオリジナルな独自の予想であるから、 もしこれが的中したら褒めてやって欲しいなぁ。 まぁ、あまりにも特徴的すぎて、この予想の当否は的中率ボロボロになりそうな悪い予感がするけれどね。

☆基本概念が当たったので個別項目もそこそこ当たった。   
当サイトの予想だが、予想がそこそこ当たったと思うのは基本概念が当たったからである。 基本概念とは、ひたすら性能を上げることはせず、コストと消費電力を抑制するという意味である。

これはライバルの製品を見れば明らかだろう。 典型的なライバルはIBMのPower7だろうから、これと比較してみよう。

Power7と比較するとSPARC64 VIIIfxのクロックは半分でしかない。 チップあたりの演算性能も半分である。 単純に性能だけ見ればIBMの方が断然優れている。

ところが、SPARC64 VIIIfxは演算性能の低下以上に消費電力の抑制効果が大きいのだ。 このため電力あたりの性能ではPower7より約1.7倍も性能がよい。 同じ演算量をこなす場合にPower7の方がずっと多くの電気を喰う事になる。

おそらくコストもPower7の方が高いだろう。 発熱が大きいので冷却のための設備がより高価になり、 またクロックの高いCPUに遅れないようにするためメインメモリも冷却され、 さらにメモリは特注品になっている。 一方、SPARC64 VIIIfxのメモリは普通のDDR3。 水冷はシステムチップだけでメモリの冷却もない。 コスト的には非常に有利だ。

また、Power7はなまじチップ内の性能が高いため、特注メモリを使っているにも関わらず B/F比ではSPARC64 VIIIfxに負けてしまっている。 メモリバンド幅はPower7の方が高いが、理論ピーク性能が2倍高い分には追いついておらず、 その結果比率としては負けている。 これは流体分野などではSPARC64 VIIIfxの方が効率が良い事を意味する。

と言うわけで、チップ性能だけ見れば一見Power7の方が優れているように見えるが、これは短絡的な見方。 総合的にどちらが優位かはジャンルにもよるし、難しい問題だろう。

余談だが、チップあたりの性能を下げてもそれ以上にコストを下げるという意味ではIBMはBlueGeneシリーズという製品を既に持っている。 ネットワークのバンド幅が狭いので用途に限りがあるしコンパイラの能力で劣るのですべての用途で売れるわけではないが、 ノードの価格は非常に安い。(だから、性能が必要ならばノードを増やして数で勝負する。) 性能を下げてもそれ以上にコストを下げるという意味では SPARC64 VIIIfx以上に低コスト側にチューニングされた製品だ。 つまり、HPCとして2製品を持つIBMが性能とコストという面で2極に立ち、 開発が1機種の富士通が両者の中間的な立場になるというのは当然と言えば当然かもしれない。

ただ、富士通はひたすら性能だけを追求せず、 トータルバランスを考えてクロック等の一部性能パラメータを意図的に下げるという方針になるだろうという当サイトの予想は的中したわけだ。 基本概念が当たれば、クロックの抑制とか、レジスタ増強とか、オンチップメモリコントローラとか、2次キャッシュ容量抑制とか、 ネットワークトポロジとかは基本概念から推定できるわけで、個別項目も当たるわけである。 (ただし、インターコネクト機能のオンチップ化とCPUアーキテクチャは間違えたけれど。) プロから見たらそれほど複雑な論理を組み立てたわけではないので予想のレベルはそれほど高くはないだろうが、 アマチュア(PCマニア)であるというレベル差を考えたらそこそこの的中度ではないかな?

☆明示的に利用できるキャッシュという新機軸。   
で、予想の的中度の話はこれ位にして、PCマニアとして技術的興味の話へ。 当サイト的に興味深い点はいくつかあって、まず一つはセクターキャッシュである。

愛読者の方にはよくおわかりだろうけれど、当サイトは以前からHPC用途ではキャッシュを推奨しない立場である。 パソコンと違ってキャッシュを増やしてもそれほど性能が高まる訳ではない場合が多いという認識だ。 だから、バンド幅の重要性を主張してきたし、ローカリティーを利用するならば 明示的な利用でデータが追い出される事を防げるローカルメモリ方式をお勧めする立場であった。

しかし、ローカルメモリにはプログラミングの難易度が高いという問題点がある。 これはCELLが圧倒的な高性能を示したにも関わらず、対応アプリの少なさで市場競争に勝てなかった点に象徴されていると思う。 (これについては、ここに当サイトの当時の意見を書き込んである。) どんなに優れたアーキテクチャでも「コンピュータ、ソフトなければタダの箱」なのであるから、 プログラミングが容易というのは重要だ。

また、キャッシュ構造とは無関係ながら、以前高エネルギー加速器研究機構を見学した際に 説明員の方からコンパイラの能力に優れていることの価値を伺ったことも強く印象に残っている。 BlueGene/LとSR11000 model K1を使い分けていて、価格性能比で劣るSR11000 model K1を別途使う理由は コンパイラ能力がBlueGene/Lに勝るからである。 この点からもプログラミングの容易性が性能に勝るとも劣らない重要項目であることがわかる。

この点でこのセクターキャッシュという方式は非常におもしろい。

まず、この工夫は当サイトが指摘した問題点がプロ間でも重要問題として認識されていた事を意味している。 つまり、HPC用途ではデータがキャッシュから追い出されるという問題点が性能低下に直結しているという点である。 同様な技術はPower7でも採用されているから、キャッシュヒットしないという問題の重大性がよくわかる。 しかし、ローカルメモリはプログラミングの観点から使いにくい。 このため、当サイトは「不適だがやむを得ない。」という観点から通常型キャッシュの採用を予想していた。

ところが、このセクターキャッシュ方式だとどうなるか? 

まず、効率が出にくくなるが通常のプログラミングが出来る。同様に過去のアプリも流用できる。 その上でセクターキャッシュを有効活用するようにプログラムを改良すれば効率が上がるというわけだ。 これは通常のキャッシュとローカルメモリという双方のメリットを取り入れた問題点の発展的解消を意味する なかなか旨い方法だと思う。

ただし、残念ながら万能というわけではない。 再利用可能なデータがキャッシュから勝手に追い出されるという問題点は解消できるだろうが、 流体用途のように本来から高B/F比な用途では、たとえデータが追い出されなくてもアルゴリズム上から原理的なヒット率が低いので バンド幅自体がボトルネックとなる。 その場合はメインメモリのバンド幅自体に勝るものは無しである。

たとえばCELLではデータを明示的に利用する。 だが、それによってキャッシュヒット率低下問題をローカルメモリの採用ですべて解消できたかというと ここで書いたとおり、明示的な利用をしてもダメなものはダメなのである。 (典型例は疎行列計算。ただし、この場合は律速はバンド幅ではなくバンク数と思われるけれど。) セクターキャッシュは通常キャッシュに明示的利用方法を提供する技術であるから、 最初から明示的利用しかできないCELLでも高速化しなかったコードに対しては効果が薄いと容易に想像できるからである。 用途の拡大という意味では非常に有意義な技術であるが、すべての用途でキャッシュヒット率の問題が解消できるわけではないだろう。

それにしても、このアイディア、当サイトがこの記事を書いたときにどうして思いつかなかったのだろう?  言われてみればまったくその通りで、コロンブスの卵というか...もう少し頭が良ければ自分でも発想出来たように思うのだけれど...トホホ。

☆技術的最適点とビジネス的最適点の妥協点を探る難しさ。   
次におもしろいのは、3次キャッシュを搭載せず、2次キャッシュも容量を意図的に抑えてあるという点である。 当サイトはレジスタ数の増強、コア数増大、SIMDの強化、オンチップメモリコントローラとかを予想したけれど、 何も考えずにこれらを全部ガンガンやっていたらダイサイズが限りなく肥大してしまう。 従って、これらを強化したトランジスタ数増加分を別な部分で減らす必要性があるのだけれど、 当サイトの意見は2次キャッシュを減らして妥協するというものであった。 これらの中でHPC用途で一番効果が薄いものは何かと考えてみたからである。

で、実機はと言うと当サイトの予想通り2次キャッシュ容量が意図的に抑えてある。 8コアなのだから1コア換算の容量は625KBとかなり少なく、廉価版CPUの代表であるAtom程度(512KB)である。

対照的なのがIBMのPower7である。3次キャッシュまで搭載され、その容量は32MB。 Power7も8コアだから1コアあたりの3次キャッシュは4MBと非常に強力だ。 eDRAMはPower7最大のアピールポイントであり、一見するとPower7の方が強力に見える。

が...HPC用途に限れば3次キャッシュ容量が大きく効く用途が多いとは到底思えない。 キャッシュが効く用途がHPC用途で多いならば演算効率で10%程度なんて低効率HPC用アプリが頻発するハズはない。 ほとんどのアプリでLINPACK同様に70〜80%出てもおかしくはないハズである。

つまり、HPC用途に限ればという限定付きであるが、当サイトは富士通の判断を強く支持する。 ダイの中のトランジスタ数は有限の資源だから、何でもかんでも増やせば良いというわけではないだろう。 アマチュアの発想だと「あれも搭載しろ、これも搭載しろ」的な発想になりがちだけれど、 効果の薄いものから削っていく発想も極めて重要であると考えている。

では、IBMは間違った判断をしたか...というとそうではなく、 当サイト的にはこう考えている。 おそらくIBMはPower7をHPC用CPUとしてではなく、サーバー用途が勝負所だと最初から考えていたのだろうと。

当サイトはPC用途ではキャッシュの効きを高く評価する立場だけれど、 もちろんキャッシュだけ増量すれば無限に性能が上がるわけではない。 容量と性能の関係は飽和曲線になるハズで、このことについてはシロウトなりに ここで考えたことがある。

また、HPCに関するプロの論文を読んだときにPower3とPower4の比較が書いてあった事があった。 当然ほとんどのケースで相対的に新型であるPower4の方が高速だけど、 データキャッシュ容量はPower3の方が大きいので例外的にPower3の方が高速なケースがあるという記載があった。 この論文から読み取れるのは、要するにキャッシュ容量が性能律速段階になるケースは HPC用途においては例外的事例ということである。

我々PCマニア間でも3次キャッシュの評判は悪い。 ゲーム用途を例外とすれば、これの効き目が実感できないという意見が多いのだ。 これはコア数の多さがPC用途では生かされない場合が多いことを考えれば当然で、 3次キャッシュは多くのコアが動いて1コアあたりの実効容量が低下して初めて効果が大きくなる。 つまり、サーバー用CPUをPC用に転用するからPCマニアの評判が悪いのである。

とすれば、IBMがeDRAMを搭載して3次キャッシュを増量した意味がわかると思う。 HPC用途で勝つためではないだろう。その意味では効果が薄い技術だと思う。 つまり、製品をサーバー用途に流用する際に、サーバー分野で勝つことを目的としているのだろう。

これを見てもIBMがHPC開発をサーバー開発に流用する事でビジネス競争に勝とうとしている事がわかる。 他分野で売れればその分一台あたりの開発費が減るから、その分製品価格を下げられるからである。 (高クロックによる高価格化をある程度まで吸収できるし、一般向けではクロックをある程度落とす選択もあり得る。) HPC用に最適化されたCPUがHPCビジネスとして最適な製品か?と考えた場合、 技術的に最適ではない製品がビジネス的に最適であると判断が入れ替わる場合があるというのは皮肉な話であるがおもしろい。

当サイトはPCマニアだから、ついつい性能だけで判断しがちな面がある。 たとえば、ベクトル機はHPC用途で非常に高い効率を誇り、純粋性能ではスカラ機を寄せ付けない。 だが、アーキテクチャ的にサーバー用途に転用できないという事が原因で 投資負担という意味で追い込まれているという状況がある。 リーマンショックでNECが次世代スパコンから撤退せざるを得なかったのはこのためで、 他分野への転用により投資負担や製品コストを低減するというビジネスモデルが使えないのである。1)

これと同様に考えれば、富士通の手法はHPC用途限定ならばIBMより最適化され優れていると思うけれど、 これがビジネスとして最適かどうかは別問題なのが難しいところだと思う。

そうそう、その意味でCPUのアーキテクチャが当サイトの予想する簡易なスカラまたはVLIWという方式を採らず、 SPARCアーキテクチャベースな事もこれで説明できると思う。

たとえば、HPC用途で最適という意味では富士通にはさらに強力にHPC用途に最適化されたアーキテクチャが考えられていた。 それはSIMD拡張スカラプロセッサというものであった。

で...シロウトなので読解は難しいのだが、頑張って論文を読んでみた。

その感想はと言うと...特徴はSIMDユニットにSBMという一種のローカルメモリを搭載している点で 当サイトの考え以上にSIMDを超強化した方向性に思えた。 当サイトは過去のアーキテクチャとの整合性とプログラミングの容易性の観点から やむなくキャッシュ採用という判断をしているからだ。

当サイトはSIMDは超強化しなければならないと予想していたが、 この試案では当サイトの予想以上にSIMDが超強化されており、当サイトの「超強化」という言葉が恥ずかしくなる位である。 性能はチップ面積あたりでは通常のプロセッサの2倍〜4.7倍。 性能面からみれば、当サイトは現行案よりも断然こちらをお勧めしたい位だ。

だが、ビジネスモデルという観点から見ると、この案だとサーバー用途への転用が出来なくなってしまう。 要するにHPC用途専用プロセッサになるから、 ベクトル機のようにHPC用途だけでビジネスを成立させなければならない。 つまり富士通がSPARCアーキテクチャベースのマルチコアを採用したのも、 ビジネスモデルとしてある程度他分野での商用販売を想定しなければならなかった事を考慮した 苦渋の決断だったのだろうと考えている。

SPARCアーキテクチャは富士通の看板であるのだから、サーバー用途転用を考えれば看板を捨てられないという事情が背景にある。 技術として最適なものがビジネスとして必ずしも最適とは言えないし、逆にビジネスとして最適なものが 必ずしも技術的に最適とは言えない、という非常に難しい事情がその背景にはあるのだろう。

ネットワークについてはトポロジ以外は未公開なので、公開され次第予想の当否を書いてみたいと思う。



1)
京速計算機からのNECの撤退はリーマンショック以前から内部で性能不足を指摘されていたというメディアの報道がある。 これには「性能」の意味に2つの解釈があると思う。

もし、性能不足の性能の意味が「LINPACK性能の不足」という意味だったら、確かにそれは正しい。 ベクトル機は多様な用途で効率が落ちない事を特徴にしているが、LINPACKはスカラ機でも性能が出るアプリだからだ。 だから、LINPACK性能だけが唯一の評価基準であるならば最初からスカラ単一機で行くべきであった。 だが、もし「LINPACK性能の不足」を意味するのだったら、 シロウトの当サイトでさえ最初から気付いている事をプロがなぜ今更こんな事を言うのか?という疑念が残る。 性能基準がLINPACK一本だとしたら、そもそも最初から複合機案はあり得ないハズだ。

逆に、これが「全HPC用アプリに対する平均的な性能の不足」という意味だったら、 当サイトはこの見解は間違いであると主張せざるを得ない。 理由を説明しよう。現段階でベクトル機最速なのはJAMSTECのES2であるが、 LINPACKがHPCの性能指標として問題があるとの指摘を受けて採用されたHPCチャレンジにおいて ES2はG-FFTとEP-STREAMの2分野で世界第3位の性能を出しているからである。 ES2はLINPACK性能だけ見れば31位でしかないが、実際には現段階でさえ2分野で銅メダルの性能なわけで、かなりの健闘を見せているのだからね。