水と油はよくなじむ(京速計算機考その3)   

2005年7月2日



☆秋葉原魅力度の低下と葉桜見物の敵討ち   
さて、最近は仕事が忙しいので秋葉原に行っている暇がない。 Webネタの更新も遅れ気味である。 ほとんどの会社で夏のボーナスが支給されたであろうが、 ボーナス支給から約1ヶ月間秋葉原に行かなかった(行けなかった)のは何年ぶりだろうか?

忘れもしないが、会社に入社して初めてボーナスが支給されたときの課長の一言。 「XX君(たるさんのこと)は、明日はこのボーナスを握りしめて秋葉原かね?」。 入社1年目にしてそういう人物であることはすでに把握されていたらしい。

なので、ボーナス支給日以降一度も秋葉原に行っていないと当時の上司が聞かされたら 「XX君は体調でも悪いのかね?」なんて言われるに決まっている。 (あ〜、そのネタは耳タコですよまったく。)

しかし、昨今の忙しさの中で秋葉原の優先順位は下がりつつあるのだ。 なんせ、もうPCパーツ系やジャンク系のショップは崩壊トレンドが止まらず、 「パソコンの街」として見た場合の秋葉原は衰退の一途を辿っている。 俺コンハウス、昨日で閉店ですか...秋葉の牙城がまた一つまた一つと...

当然、趣味の街としての魅力も低下するわけで、最近は秋葉原に行ってもPCパーツショップではなく 「あの、おんぼろアナログ・オシロ買い換えたいなぁ〜。」なんて、 東洋計測器(中古も扱う計測器屋さんです。)あたりでぶらぶらしている時間が長いような気がする。

今、秋葉原の隆盛はメイド系ショップに代表される非PC系ショップが支えていて、 昔と違ってカップルや女性客も増えてきた。 電気街と言うよりは観光地といった感じかな?

象徴的だったのが最後に秋葉原に行った日のこと。 秋葉原駅を降りたらダイビル前でメイドさんがビラ配りをしていて、 ヤマギワ前の交差点まで歩いたらまたメイドさんがビラ配りをしていて、 裏通りに入ったらまたメイドさんがビラ配りをしていた。 流行物もここに極まれり、である。

昔はビラ配りといえばパソコン系だったわけで、 「激安・激安・激安ぅ。超〜高性能ぅ。」なんてかけ声で、某宗教系問題児ショップがビラ配っていて 「おまえらオレの秋葉原からとっとと出て行きやがれ〜。」なんて内心思っていた時代もあったけど、 (人の趣味にはいろいろあるからメイド系が悪いという意味ではないが) 秋葉原歴20年近くになろうとする目で見れば当サイト的趣味の街からはだんだん遠のいているかなぁ〜。 (遠〜くを見る目。)

☆複合機は、まずハンデから始まる。   
さて、前回からの続きである。 では複合機というアイディアはどうなのであろうか?

この複合機というアイディアは理研RSCCや連結階層シミュレータに代表される 最近のトレンドである。また以前は日本独自の動きと書いたこともあるがこれは間違いで、 最近ではアメリカでも同様の動きが出てきているようである。

たとえば、 米Crayがベクトル型スーパーコンの新製品を開発,コストは1/3に という記事を読むと、最新鋭機BlackWidowはスカラ型ブレードとの混載を意識して設計されているようだ。 (この記事を読むためには日経Tech-On!への登録が必要。)

これら複合システムはマルチフィジクス、マルチスケールの問題を解くために最適化されるという事が特長の一つとされている。 例えば連結階層シミュレータでは自然界の事象を階層に分けたとき、 複数の階層にまたがるシミュレーションでは階層間にあまり最終結果に影響を及ぼさない領域が 広がっている事が多い事を利用して、階層別に異なるアーキテクチャのマシンで計算を行うそうだ。 (たとえば、マクロ階層シミュレータはベクトル機、ミクロ階層シミュレータはスカラ機。)

シミュレーションのレベルを上げるとき、単純に すべての領域を演算性能に任せて力技で細分化するのではなく、 階層構造を利用して階層と階層の間の無駄な領域分の計算を省こうという発想だ。

これは使い手側の要求から求められた事項であり、Web上で少々調べてみたが 作り手側の要求事項についてはあまり記載がない。 このため、今回は使い手側ではなく作り手側、つまりアーキテクチャや製造面的な要求事項から この複合機というアイディアについて考えてみた。

作り手側として、複数のシステムを複合するというメリットは何だろうか?

実は、当サイトがポスト地球シミュレータを最初に考えた際には、 複合機というアイディアをまったく考えなかったわけではない。 (考えた時間は、おそらくは数分程度であろうか...)

だが、当時は不勉強にしてマルチフィジクスという概念もマルチスケールという概念も自分の頭の中ではまったく欠落していたので、 従来型アプリに対して複合機が妥当かどうかだけを考えていた。 このため、わずか数分で「これはうまく行かない。」と判断して却下していたのである。

単純に考えると、実は異機種複合システムというのはメリットよりデメリットが多いように思う。

例えば、プログラミングは機種毎に最適化条件が違うので当然複雑化する。 複数の機種を全て網羅して高レベルなプログラミングの出来るハイスキルな人材はそれほど多くはないだろうし、 その手の根性の据わった人物が仮に居たとしてもどこの職場でも奪い合いになるだろう。 「コンピュータ、ソフト無ければただの箱」という有名な川柳があるが、 これはパソコンからスパコンに至るまでおそよコンピュータと名のつくものには至言であると思う。

また、スパコンの総合性能はもっとも遅い部分で決まるという当サイト的原則を適用すると 2機種複合の場合は2機種とも高効率化しないとシステム全体が高効率にならないだろう。 これは、アムダールの法則を逐次実行部分と並列実行部分ではなく各機種の性能に当てはめて考えればよくわかる。 そして、当然の事ながら3機種ならさらに制約事項が増す。

また、単一アーキテクチャ機に比べると機種間の演算性能配分も自由度が減ってしまう。

どういう事かというと、例えば理論ピーク性能10PFLOPSの単一機と、 それぞれ5PFLOPSで合計10PFLOPSの2機種複合機があったとする。 その場合、複合機では都合良くそれぞれに要求される性能が50%づつに配分されるかというと、 そのような保証はどこにもない。 もちろん、アプリが1種類だけならば事前に最適バランスをシミュレーションして FLOPS値を配分すればいいわけであるが、汎用機である場合にはアプリ毎に最適配分が違うので難しいのである。

これはマルチフィジクスでもおそらく同様である。 マルチフィジクスを解く場合に、演算性能の配分がフィジクスAとフィジクスBで5PFLOPS づつ必要な場合ばかりかというともちろんそんなことはなくて、 フィジクスAは1PFLOPS程度でかまわないが、フィジクスBは9PFLOPS必要とか、 別のアプリでは1:2程度が最適配分とか... もちろん「最適配分でなければ動作しない。」というわけではないが、少なくとも効率がかなり悪くなりそうだ。

しかし、単一機ならば機種内でノードを振り分けることは自在である。 実際、地球シミュレータでは余ったノードがあれば別の計算を走らせるなどして使用効率を上げている。 (640ノード中400ノードはアプリ1で使用し、200ノードはアプリ2で使用といった感じ。 当然比率は自由に変えられる。) また、メモリ容量に余裕があれば同一ノードで切り替えながら走らせる事だって可能かも知れない。

もちろん、複合機でも一機種で最大性能を出したときにもう一機種の性能が余ったとすれば、 余ったノードには別件のアプリを走らせて穴埋めすることは可能である。 しかし、その場合は低性能な側の機種が全体の性能をリミットするのであまりよろしくない状況だと思う。 (基本的にスパコンは常に最大性能を狙って使うべきで、ノードの分割使用は演算リソースの無駄遣いであろう。)

要するに、複合機とはNet-Burstのクロックと内部RISCの関係に似ている。 Net-Burstはx86を細かなμOPsに分解する事で内部動作を単純化している。 その結果ハイパーパイプラインを可能にし高クロックを達成していた。 しかし、細かなμOPsに分解すること自体はμOPsベースでのIPCの割にx86ベースでのIPCが低くなることを意味し、 それ自体は損な方式である。しかし、それを上回るほどに高クロック化が達成できるために、 それによってハンデを乗り越えるメリットを得て、その結果総合的には高速化する訳である。

複合機も同様で、まずハンデから始まるのであり、ハンデを乗り越えるメリットが生じて初めて 効果的になる方式であると言えるのではないだろうか?

☆複合機のコツは「損して得取れ。」   
とまあ、問題点を考えて数分で却下してしまった訳だが、 これがプロの言うところのマルチフィジクスやマルチスケールだとどうだろうか?

少し状況が変わって、これだとデメリットを上回るメリットが出てくる可能性が高いと思う。

まず、前作の中で 「性能を向上させたいときに何を改善すればいいのかは、アプリのByte/FLOPによって異なる。」と書いた。 この場合アプリによって最適動作点が異なるので、全てのアプリに対して有限のリソースで最適なCPUを設計する ことは現状では不可能である。 (最近はリコンフィギュアブルという方式が流行だが、リコンフィギュアブル構成をもってしても 浮動小数点演算能力とメモリのバンド幅の関係はリコンフィギュアブルではないので、やはり不可能だ。)1)

たとえば、当サイトは高Byte/FLOPであることが科学技術計算においては重要だと考えているが、 それがいかなる場合でも成り立つかというとそうではない。 高Byte/FLOPを必要としないアプリではメモリのバンド幅に費やすリソースとコストを 浮動小数点演算能力に投入した方がよい性能をだせるだろう。 (典型的なのがMDである。)

汎用という意味では高Byte/FLOPでないとアプリによって性能が極端に乱高下することになるため難しいが、 低Byte/FLOP領域のアプリに限定してしまうならひたすら浮動小数点演算にリソースを投入するのが良いわけであり、 実際BlueGene/Lはそのような方面に最適化する方針を取っていると見る。 それは、ネットワークの処理能力との絡みで高Byte/FLOP領域を捨てる代わりに低Byte/FLOP領域で極限の高性能を目指すという意味である。 (だから当サイトは同機を準汎用機と表現したのである。)2)

ならば、マルチフィジクスやマルチスケールのアプリならばどうなのであろうか?

マルチフィジクスにおいてフィジクスAもフィジクスBも高Byte/FLOPまたは低Byte/FLOPならば 単一機でそれに合わせた最適設計をすればいいことになる。 しかし、フィジクスAが高Byte/FLOPでフィジクスBが低Byte/FLOPだったらどうだろうか?

たとえば地球シミュレータのような巨大単一ベクトル機の場合を考えてみよう。 フィジクスAでは高性能を出せるし、今のところ他にこの分野で高性能を出せる機種がないから ライバルもいない。しかし、フィジクスBではどうだろう? 

効率はスカラ機と同程度だから実性能は悪くはならないが、 同じ性能を出すのにスカラ機に比べてきわめて高価格で消費電力も大きいシステムを使用している事になる。 処理効率が同じでは流体系アプリのように効率面でコストパフォーマンスを逆転させる技も使えないので、 おそらくこの部分で「コストパフォーマンスが悪い。」と批判されるだろう。

ではBlueGene/Lではどうだろう。 低Byte/FLOPのフィジクスBを計算する場合は、高性能でかつ価格も安いからベストだろう。 しかし、高Byte/FLOP領域では効率が1%にも達しない例があって、 いくらコストが安くても実性能が不足してしまうと言う問題点がある。 おそらくこの部分で「効率が低すぎて実性能が足らない。」と批判されるだろう。

ではここで、規模を縮小したミニ地球シミュレータと規模を縮小したミニBlueGene/Lを結合したようなシステムが あったらどうだろう。(両者を足した総計のハードウエア量では同じ規模とする。)

フィジクスAをミニ地球シミュレータで、 フィジクスBをミニBlueGene/Lで実行すれば、お互いの弱点を補完しあえる事になる。 巨大単一ベクトル機とほぼ同じ性能を、BlueGene/L並みとは言わないまでも 巨大単一ベクトル機よりずっと優れたコストパフォーマンスで実現できる可能性があるわけである。

とまあ、マルチフィジクスやマルチスケールなら先に述べた弱点を上回る長所を得ることで、 トータルで高性能・低価格を実現できる可能性が高いわけだ。 (ただし、下手に作ると弱点同士が表に出てきて大失敗となるわけで、 これをうまくやるのがソフトウエア開発の腕であろう。)

ちなみに、補完し合う項目は先のコストとByte/FLOPの関係のみにとどまらない。 スパコンの抱える問題点それぞれの項目について、それぞれ相反する項目は (旨く設計すればだが)補完し合うことが出来ると思う。

そこで、いろいろな項目について各アーキテクチャ毎に一覧表にしてみた。 (各方式のプロ毎にご意見があるでしょうが、一般論として考えてください。)

方式 CPUの理論ピーク性能 CPU毎の実効メモリバンド幅 実効効率(高Byte/Flop) 実効効率(低Byte/Flop) 汎用性 コスト 消費電力 高並列対応
スカラ(コンベンショナル)
スカラ(超並列) ×
ベクトル × × ×
疑似ベクトル
専用機 × ×

注意点としては、下記の点がある。 高並列性についてはネットワーク構成との関係が深いので厳密には アーキテクチャ毎には一般化できない。 可能性を組み合わせ毎に全部検討するのはシロウトには難しすぎるので、 実機を参考にベクトル機では単段クロスバ、疑似ベクトル機では多段クロスバを前提にしている。 (ベクトル機でもネットワークのトポロジを変えれば高並列は可能と思われる。)

また、専用機は汎用性の点では一般的見解に従って×としたが、 今後出てくるGRAPE-DRではこの点が大幅に改善されているであろう点は含まれていない。3)

☆水と油がよくなじむ。似たもの同士じゃ意味がない。   
さて、上記の表を見てうまい組み合わせはどれだろうか?

まず一つ言えることは、すべてにおいて完璧な方式は無いということ。 その昔、「ベクトルパラレル機は死んだも同然。」という主張がなされたことがあったが、 この主張が成立するためにはベクトル機に対してすべてにおいて勝る方式が存在しなければならない。 だが、そのような方式は見ての通り存在しないから、この発言はミスリードである。

そして、それぞれに一長一短のある方式ばかりだから、 これなら組み合わせ次第で複合機もうまくいく可能性があるわけだ。

では、どの組み合わせが一番いいのであろうか?

探索の指針は「弱点を補完しあえる方式を選べ。」という点である。 つまり、◎×の関係がはっきりしていて、 しかも関係が逆転している方式同士がベストというのが当サイトの判断である。

その目で一覧表を見てみると、本命として一番良いのはベクトルと専用機の組み合わせだ。 ベクトル機と専用機は長所と短所の出方がはっきりしていて、しかも関係がまったく逆であり、 まさに水と油の関係にある。しかし、複合機の場合は水と油だからこそよくなじむとも言えるわけで、 プログラミング次第でお互いの弱点を補完しあえる可能性が一番高い組み合わせと言える。

対抗馬はベクトル−スカラ超並列の組み合わせだろうか。 地球シミュレータとBlueGene/Lのような組み合わせである。 こちらの方は補完関係がベクトル−専用機より弱い弱点があるが、 専用機の場合は実行できないアプリが考えられるので、 リスク分散というかバックアッププランという意味ではこちらも考えられる。 (その意味ではGRAPE-DRによる汎用性拡大に期待だ。)

そして三番手は疑似ベクトル−専用機といったところである。

逆に、スカラ超並列−専用機とか疑似ベクトル−ベクトルという組み合わせはあり得ない事がわかる。 複合機の場合は似たもの同士では意味がないし、また長所短所のメリハリが効かない方式も向いていないと言える。 このような組み合わせを作るくらいなら、どの方式にせよ巨大単一機を作るべきであろう。

また、コンベンショナルなスカラ方式はすべてが中庸であり、よく言えばバランスが良いと言えるかも知れないが 少なくとも複合機には向かないと予想される。

さて、上記では2機種複合を考えてみたが、現状での京速計算機は3機種複合となっている。 (大規模処理計算機部・逐次処理計算機部・特定処理計算加速部の3種) 常識的に考えれば大規模処理計算機部はベクトルまたは疑似ベクトル機、逐次処理計算機部はスカラ方式、 特定処理計算加速部は専用機を意味していると思われる。

3機種複合の場合「弱点を補完しあえる方式」という当サイト的判定方法から見ればどうだろう?  この場合、3機種の長所短所はじゃんけんのグー・チョキ・パーのような関係になっていなければならない訳だが、 上記一覧表ではそうなっていないのが問題と考える。

仮に逐次処理計算部がスカラ方式を意味していると仮定すると、 その特性がベクトルと専用機の中間になってしまっていて「弱点を補完しあえる方式」の関係になっていない。 ベクトル機から見れば己の弱点はスカラ機より専用機の方が効果的に補ってくれる訳であり、 専用機から見た場合もまた同様であろう。

3機種複合は2機種複合ではどうしてもカバー出来ない何かがあるときだけやむを得ず検討するシステム、 と考えた方がいいのでは?と思うけれど、どうなのであろうか?

さて、こうして考えてみると複合機というのは「世の中には不完全な方式しか存在しない。」 という事を認めた上で成立する方式であると言えると思う。 もし仮に万能な方式があれば、それを使った巨大単一機の方がよい。

しかも、マルチフィジクスやマルチスケールの問題を考える上で、各フィジクスや各スケールが それぞれ異なる方式になじむ場合に適合しており、たとえばマルチフィジクスにおいても 両者が連続体シミュレーションの場合とか、両者が粒子コードの場合とかには不向きである事も予想できる。 少なくともマルチフィジクスやマルチスケールを解く場合に複合機が必然というわけではないと思う。

と言うわけで、複合機は無条件で成り立つ方式ではなく、おそらくは 自然界の階層が異なるだけではなく、それを解くアルゴリズムの性質も異なっていなければならないと考える。 ただし、それが成立した場合には高性能と低コストを両立できる可能性が高く、 開発リスクとしてはハイリスク・ハイリターン型と考えられる。 (失敗が許されない巨大プロジェクトとしては、この点でちと心配である。)

☆京速計算機頑張れ!   
そうこうしているうちに、LINPACKベンチマークベースのTOP500サイトが更新され、 BlueGene/LがFPMD(第一原理分子動力学)系アプリで207TFLOPSを達成し、 東工大のTSUBAMEシステムが公開され、理研のMDGRAPE3が公開された。 まさにドッグイヤーであり、世の中の進展は著しい。 (理研のMDGRAPE3は6/24に一般公開されたので是非見学に行きたかったのだが、 例によって土曜日は仕事でダメなので見そびれてしまった。)

TSUBAMEシステムはTOP500で7位にランクインしたが、 好感が持てるのはLINPACKで不利になることを承知でCPUにOpteronを採用したことだ。 LINPACKで勝つ事が目的なら少なくとも積和演算に特化した命令を持ち、理論ピーク性能の高いCPUが有利であり、 Itanium2なりPPC970なりもっと良い選択肢はあったハズである。 だがTSUBAMEはそれをやらずに(スカラとしては)Byte/FLOPが良くなる道を選んだ。 PCクラスタという制約の中では正解であろう。

また、BG/Lの207TFLOPS達成であるが、高効率を出しやすいFPMD法ということで効率的には極端に高いわけではないが、 実性能で100TFLOPSを超えたのはやはりマイルストーンとして意義があるし、 あれだけ多数のプロセッサを持つシステムで達成している点には素直に感服だ。

ただし、BG/Lはプロセッサ数が通常より一桁以上多いだけに 効率を上げるためには問題規模も一桁以上大きくする必要があるハズである。 原子数が1000個以上と多いのは確かに成果でもあるのだが、実は性能を維持するための必要条件でもあると思われる。

スパコンの真の意味での性能向上が停滞しつつあると言われて久しいが、 それでも最前線の技術者はそれぞれに頑張っているようである。 理屈で考えると京速計算機の前途は難問山積みのように思うのだが、 これならば京速計算機も期待できると少々希望を持った今日この頃である。4)

さて、京速計算機ネタは書こうと思えばネットワーク系等についてまだまだ考えるべき点は多いわけだが、 同じネタが3回も続いているため、おそらく4回目は自他共に食傷気味であろう。 なので次回は別ネタで一息入れたい。



1)
では、理論ピーク性能とメモリのバンド幅を再構成できるリコンフィギュアブル・プロセッサという物が 仮に設計できたとしたらどうだろうか?

おそらくクレイのベクトル機に匹敵するスパコン界の大革新になると思う。 なぜならば、汎用機の汎用性と専用機の高効率をあらゆるアプリで両立できるマシンになるからだ。

ただし、当サイトのトリ頭ではそんなプロセッサを製造するアイディアはまったく思い浮かばないし、 具体的な方法が思いつかない以上、「常温で超伝導の物質を発見できれば、科学界の大革新になる。」 と言っているのと同じで、「間違っているわけではないが、意味のない意見」の典型である。 誰か良いアイディア、お持ちではないでしょうかねぇ。

2)
ちなみに、TOP500で世界一になるのに都合がいいのはLINPACKがまさにそのような性質を持っている事である。 LINPACKは典型的にメモリのバンド幅を必要としないアプリである。

3)
従来のGRAPEシリーズはLINPACKベンチマークを実行できなかった事でわかる通り、まさに専用機であった。 だが、GRAPE-DRは同じGRAPEの名を冠してはいるが今までのGRAPEシリーズとはまったく設計思想が異なっている。 性能リソースを浮動小数点演算能力に特化している分高Byte/FLOPアプリは苦手と思われるので、 その意味では事実上は準汎用と考えた方がよいだろうが、少なくとも原理上では汎用である。 だから弱点であった汎用性は大きく改善されると思われる。

4)
と...ここまで書いてきたら、とある読者の方から牧野先生のサイトが更新された旨のお知らせメールを頂いた。
京速計算機はどうなってるか を 読んでみると、比較的お勧めなのはVPP(ベクトル機)+GRAPE(専用機)だそうだ。

更新日が同じ7/2でありベクトル−専用機を本命と考える理由書きも内容がまったく異なるから、 当サイトの内容が同記事のパクリではない事はおわかりいただけると思うけれど、 プロと同じ意見というのはなんかちょっと嬉しいぞ。 v(^_^)