脳みそのシワ、+1本。(次世代スパコン計画案決まる。)   

2007年6月23日



☆何事も正統派の勉強は大切。   
少し前の話だが、将棋の渡辺明竜王が将棋ソフトのボナンザと対戦したというニュースがあった。

勝負は竜王が終盤で放った3九龍という妙手が決め手となってプロ棋士が順当勝ちするものの、 ボナンザは負けたとは言え中盤戦までは互角に戦ったそうだ。 ちなみに、コンピュータは序中盤戦よりむしろ終盤戦が強いので、 普通は形勢互角で終盤戦になだれ込んだら多くの場合で人間側の負けとなる。 さすがは人間代表、タイトルホルダーの面目躍如である。

日進月歩の世界だから、チェスのようにコンピュータがタイトルホルダーを打ち負かすのも時間の問題なのだろうが、 これがボナンザの成長ぶりを印象づけたかというと、当サイトはその日が来るのは世間の予想より遅いとの印象を持ったね。 無敵であったはずの終盤戦でさえプロに届いていないのだから...

と言うわけで将棋ソフトの話なのだが、ずいぶん以前になるが当サイトも余談で将棋ソフトの話を書いたことがある。 コンピュータの設定レベルを落として対戦するのがイヤで最強モードのまま戦い続けていたら何と40連敗を喫してしまった話だ。 このソフトは東大将棋4で、今となってはそれほど最新と言うわけでもないのだが、 それでも将棋ドシロウトの当サイトにとってはイヤになるほど手強いのである。

その対ソフト戦の連敗が最近ストップした。 相手が振り飛車戦法で来た場合に限るが、東大将棋4に何回かに1回は勝てるようになったのである。

理由ははっきりしている。 正統派の勉強が効いたのだ。

当サイトは別段将棋マニアという程の事もなかったので、 東大将棋4とやるときはいつも我流で戦っていた。 しかし、自分が弱いからと言ってたかがパソコンごときに 手心を加えられるのは嫌なので、先ほど述べたとおり負けても負けても最強モードで戦っていたのである。

それで、ついに40連敗...というのが前回までの段階。 いや、それ以降も相当に負けが込んでいたんだけどね。

で、あまりにも負けが込むので「こりゃイカン。」と思い、 ついに真っ当なちゃんとした棋書を読んでみた。 田中寅彦九段著「実戦・居飛車穴熊戦法」という本だ。 (以下、将棋をやらない人にもわかるようになるべくイメージだけで話しますが、将棋をやらない人には難しい話ですみません。)

この居飛車穴熊戦法という戦法は相手が振り飛車戦法という特定の戦法で 攻めてこないとできない戦法なんだけど、東大将棋4は1/2位の確率で飛車を振ってくるんだよね。

で、読了後再戦。何手か進んでとある局面に...

この本をお手持ちの方は14ページをごらん頂きたい。 当サイト(居飛車穴熊側)が6八角と角を引いた時点で通常は振り飛車側は向かい飛車戦法に作戦変更するのだが、 なんとコンピュータは2筋に飛車を振ってこない。 え〜、これって、棋書で「(居飛車穴熊側に)恐ろしい狙いが秘められている。」って 書かれている局面じゃないか...

早速、棋書で勉強した通りに飛車角交換を挑み、4一角から「露骨な攻め」で攻勢へ。 棋書はこの局面以降は居飛車穴熊有利と判断して、別の局面の話に話題が切り替わっているのだが、 この先も穴熊の堅陣を生かして角金交換からガジガジとスッポン攻めで攻めていく。

棋書に解説がない局面での戦いなので凄い勢いでコンピュータが差を詰めてくるのだが、 最後は敵玉を端に追い込んで9筋からアッパーカット。 何とか逃げ切り勝ち。 まったくの実力で最強モードのコンピュータから勝ち星を挙げることができた。

いやいや、古いソフトとはいえ実力でコンピュータの最強モードに勝ちましたよ。 やはり正統派の勉強は効くね!!!

☆コンピュータでも正統派の専門書を買う。   
と言うわけで、何事も正統派の勉強は大切という事がわかった段階で、コンピュータの分野でも専門書を買ってみた。 今回買ったのはこちらのサイト でも紹介されているペタフロップスコンピューティングというスーパーコンピュータの専門書だ。

まじめに正統派の勉強をしてみた。
将棋では早速効果あり! 

スパコン分野の専門書というのは結構数が少なくて、神田神保町の三省堂や書泉グランデに行っても そんなに多くの本が見つかる訳ではない。それに日進月歩の世界だから初版が古い本だと知識も古くなってしまう。 かといって、某ネット通販でスパコンの専門書を探してみたら抱腹絶倒の本を推薦されたりするのは相変わらずで、 今回も検索語彙「スーパーコンピュータ」で検索したところ「ときめきメモリアル Girl's Side 2nd Kiss」が18位で引っかかってきた。(笑)

前回の免疫があるので、さすがに生卵かけご飯を吹いたりはしなかったが、 いったいama○○○.comの検索システムはどんなアルゴリズムになっているんだい???  「いや〜、ロングテール部分ではこういう検索アルゴリズムの方が売り上げが伸びるんですわ。実は...」 なんてことがあるとはとても思えないのだけどね。

さすがに「ペタフロップスコンピューティング」という語彙では目的の1冊しか検索にかからなかったので、早速発注。 勉強不足で意味のわからない部分は一部すっ飛ばしたので、週末の1日で一気に読了。 一部で知恵熱を発症したり、個人的にビックリ仰天した部分1)もあったが、 これで当サイトのトリ頭も脳みそのシワが少しは増えていることであろう。

ちなみに、この本の著者と ここのサイトの先生の見解は本の紹介内容から見てどうやら論争の真っ最中というライバル関係にあるらしい。 客観性を求めるなら両方読んで自分自身で見解をまとめてみるのが良いだろう。 一番見解が対立しているのは理論ピーク性能とバンド幅の重要性の認識の違いと、コストパフォーマンスの観点だろうか?

当サイトの考えはすでにByte/FLOPが決め手(京速計算機考その2) に書いたが、Byte/FLOPの高い領域ではベクトル機が性能面はもちろんのことコストパフォーマンス的に見てもお勧め、 Byte/FLOPの低い領域ではコストパフォーマンスでスカラ機がベクトル機を圧倒、というシロウトなりの結論を導き出している。

専用機ならアプリのByte/FLOPを事前にシミュレートして推定値と一致するように設計すればいいわけであるが、 汎用機の場合はいろいろなアプリが考えられるので、アプリ次第で優劣は変わる。 ベクトル機とスカラ機の優位性が入れ替わるのは下図の通りスカラ機のバンド幅リミットとベクトル機の理論ピーク性能リミットの クロスポイントとなると言うのが当サイトの考え方。

つまり、勝負の分かれ目は「どちらの長所がいかに優れているか?」ではなく、 「どちらの短所がいかに少ないか?」で決まる...というのが当サイト流の判断である。 (要するにコンピュータの総合性能はボトルネック部分で決まるから、ボトルネック同士の戦いとなると言うことだね。)

以前掲載したベクトルとスカラのクロスポイント。
クロスポイントは両者の弱点同士がクロスする部分である。
決して長所同士の戦いではない。

この本を読んで勉強して目から鱗だったのは、スパコンではストレージの役割が思ったよりもとても重要だという事だろうか?

当サイトがスパコンの話を書くときにストレージの話をメインで書いたことはない。 これは、当サイトがストレージを「演算結果を保存するための補助的な部分」と思っていたことによる。 本書によると実はそうではなく、CPUやメモリと同様にスパコンの中核部分の一つという事になる。

余談だが、ここに書いたとおり当サイトはMADCAPベンチマークの結果から 地球シミュレータの弱点はI/O部分にあると読んでいた。 ペタフロップスコンピューティングによると4ページに地球シミュレータの問題点の一つとして 「計算処理能力と計算結果の二次データ処理能力がアンバランスである。 CPU処理能力に比較して、外部記憶装置能力、図形処理能力などの二次処理能力、あるいは大規模データマネジメント機能が低い。」 という指摘が成されている。

今回は以前の予想がかなり間違っていたという話をするわけだが、 負け犬話だけでは悔しいので少しばかり自慢話をすると、 この点に限って言えば当サイトの推測はズバリ的中していたと言える。 (この本の著者のお一人は地球シミュレータの開発に直接携わっていた方なので間違いない。)

☆京速計算機計画案が決まる。(NEC-日立案予想間違えました編)   
さて、当サイトが扱うスパコンネタであるが、次世代機「京速計算機」の概要が決まったようである。 次世代スパコンはスカラーとベクトルの複合型に,日立/NEC/富士通の「3社連合」で開発へ という記事に掲載されているが、紆余曲折を経て結局はスカラとベクトルの複合機案に決まったようだ。

この計画案であるが、興味深いのは元々がベクトル案とスカラ案に分かれていたが、結局それらを統合して複合機案とした点である。 当サイトは以前この計画に関して 予想を書いていて、これは2社合同案はベクトル-専用機複合機案、 1社案はスカラ超並列案と予想していた。

ここで、結局複合機案に決まったんだから予想が的中していたかというとそうではない。 元々の2案が非公開で、決定された最終案についても中身の詳細については非公開となっているから これも推測になってしまうのだが、複合機案と言っても当サイトの予想とはずいぶん毛色の変わった構成である。

まず、予想が外れた点をいくつか指摘してみよう。

元々の案ではベクトル機案とスカラ機案に分かれていたそうであるから、 NEC-日立案がベクトル機案、富士通案がスカラ機案であろう。 そうすると、NEC-日立案はベクトル機による巨大単一機案であった事になる。

当サイトは10PFLOPS級のマシンでは単独のベクトル機はおそらくは作れないだろうと考えていた。 作ることが出来るならば作るべきであるが、物量限界により2012年の技術水準では難しいのではないかと考えていたのである。 (この詳細についてはシロウト思考で行く(京速計算機考)をご参照ください。)

しかし、NEC-日立案が単独のベクトル機案だったとすると、 10PFLOPS級のマシンが単独のベクトル機で可能だったという事になる。 つまり、当サイトの根本的な予想が外れていたわけだ。

これはいったいどういう事だろうか?

巨大なベクトル機が作りにくい理由は当サイトの考えでは主に3つあって、 一つはネットワークが地球シミュレータと同様の単段クロスバだとすると物量限界が近いからというもの。 これはおそらく単段クロスバをあきらめたのだろうと予想している。

また、単段クロスバはノードの増設が容易ではない。 しかし、公開情報によれば完成後のノード増設も視野に入れているようだから、 その意味でも単段クロスバは可能性が低いと思う。

もう一つはノード内のCPUとメモリとの接続トポロジ。 当サイトはネットワークのトポロジとCPU-メモリ間の接続トポロジには一貫性がある必要があると考えており、 実際、地球シミュレータの場合ではノード内の8つのCPUはいずれのメモリバンクにも任意に接続できる構成となっていた。 これはネットワークでは単段クロスバに相当する。

しかし、ネットワークのトポロジとして単段クロスバをあきらめるならば、 ノード内のメモリバンクを全CPUに対してクロスバ接続する必要性はかなり薄まると考えている。 CPU-メモリアクセスとノード間アクセスは、結局の所データを演算ユニットに送り届けるという意味では同じだからだ。 一方で特定のボトルネックが生じるなら、もう一方で生じるボトルネックも同種のものがよい。 つまり、システム全体としての整合性の面から一方だけが単段クロスバ相当である必要性は薄いと考えている。 と言うわけで、ここをメッシュなり、ファットツリーなりにトポロジの次元を落としたのではないだろうか?

そして最後にして最大の難関はベクトル機の本質であるByte/FLOPの維持である。

ベクトル機最大の難関はByte/FLOPの維持にあるわけだが、 これをあきらめれば開発リスクもコストも大幅に低減できる。 もちろんデメリット無しでこれが可能ならばバラ色の話なのだが、 ベクトル機の場合はこれは実効性能の低下に直結するから、ある意味では禁じ手でもある。

CrayX1ではこの対策としてベクトル機にキャッシュを付けるという方法が採用された。だが、 この方法は地球シミュレータとのベンチマーク比較で全敗という結果をもたらした。 だから、次世代スパコンではおそらくこの方法は採用されなかったことと思う。

キャッシュに代わる方法としてはベクトルレジスタを増やす方法と、 CELLのようなローカルストアメモリをオンチップに搭載するという方法が考えられるが、 このどちらかを用いてByte/FLOP低下のダメージを最小限に食い止めようとしたのではないだろうか? 当サイトではCELLにおけるローカルストアメモリが意外に活躍するという話を論文で読んで紹介したことがあるが、 その結果から推定するとローカルストアは意外にも挙動がキャッシュ的ではなく、従ってHPC用途とは比較的相性が良さそうだ。 (ちなみに、プロによると貫通電極によるメモリチップの直接接合という手があるそうだから、 そうするとローカルストアメモリが有力という事になる。)

当サイトはByte/FLOPの維持を重要視する立場なので、この方法は個人的にはあまりお勧めできないようにも感じる。 だが、先に紹介した専門書によると、Byte/FLOPの維持は理念としては正しいものの現実問題としてByte/FLOPの維持は困難になりつつあるようである。 (現実的なByte/FLOPでも性能低下を最小限に止めるために、専門書では純粋なベクトル機を離れ、 SIMD演算機構を活用したマトリクスレジスタ計算機という概念が紹介されていた。)

実はベクトル機では内部の演算性能を上げること自体はメモリのバンド幅を上げることよりは難易度がずっと低い。 従って、当サイトの述べたような対策でByte/FLOPを下げることによるダメージを最小限に留めることがもし可能ならば、 理論ピーク性能を高めることは不可能ではないと思う。

しかし、そうすると最大の疑問点はなぜ日立が協業しているか?という点だ。 当サイトはベクトル機-専用機複合機を予想していたわけだが、純粋ベクトル機の場合は日立が協業する意味がわからなくなる。

で、この回答は先に述べた本での正統派の勉強が教えてくれる事になる。 それは先に述べたストレージの重要性が原因なのではないだろうか?

地球シミュレータの数少ない弱点として、先に紹介した専門書ではストレージがCPU性能に比較して弱い点を指摘していた。 また、ストレージがスパコンに果たす役割は当サイトの認知よりずっと重要であることも教えてくれた。 とすると、NEC単独ではなく日立と協業する理由として、日立の持つストレージの技術力が浮かび上がる。 実は日立はストレージ系に関しては優れた技術力を持っている事で有名だ。 (当方の記憶間違いでなければ、ディスク・ストレージシステムのシェアは日本一ではなかったかな?)

と言うわけで、公開情報から当サイトの予想が外れていたことを素直に認めた上で、下記のように予想を修正してみた。

☆☆京速計算機計画案が決まる。(富士通案予想間違えました編)   
さて、では次に富士通案だが、これも予想を間違えた。

富士通案はスカラ機ベースであって、これは予想が的中した。 だが、この部分の予想は「大学入試センター試験の国語の問題では漢字の問題が必ず出題されるでしょう。」 と予想するようなもので、誰でも的中させられる予想であって全然自慢にはならない。

予想をミスったのは、まずアクセラレータが搭載されること。 もう一つはおそらくはスカラといってもBlueGene/Lのような超並列タイプでは無さそうであるという点だ。 つまり、おそらくは東工大のTUBAMEシステムに似たような形式になると言うことだろう。

アクセラレータといっても世の中にはいろいろなものがあるが、実用性のあるアクセラレータには特徴がある。 それはGPGPUを例外とすれば、当サイトの知る限りにおいてすべてのアクセラレータがByte/FLOPの低い領域を得意とすることである。 つまり、GPGPUを使用するのでなければ、このシステムはLINPACKやMDの様な用途を念頭に開発されたものだろう。 スカラプロセッサはアクセラレータが計算できない部分、つまり処理は複雑だが演算量は少ない部分を担うことになると思われる。 直線部分はF1マシン(アクセラレータ)が走り、曲がりくねった山道はWRCマシン(スカラプロセッサ)が担うイメージだ。

もう一つ予想を間違えたのは、アクセラレータの相棒がスカラであること。 当サイトはアクセラレータの場合の相棒としてはスカラよりベクトルが適していると考えていた。 しかし、後講釈になるので少々後ろめたいのであるが、 例えばGRAPE-DRなどは本来はPC上の拡張ボード扱いだから、設計の手間を考えればスカラマシンの方が問題が少ないとは指摘できる。 (チップの特徴からはベクトル機との複合が相性が良いと個人的には思っているが、こちらは実践例が無いから開発リスクは大きいと思われる。 スカラと組むのはリスクマネジメントと考えれば説明できるだろう。)

このような用途の場合は、ネットワークはレイテンシさえ良好であればバンド幅は比較的不要な場合が多いから、 そこそこのバンド幅を備えた構成で問題ないと思う。 つまり、レイテンシ面で不利なメッシュではないと思う。 (メモリのバンド幅が必要な用途ではネットワークもバンド幅が必要で、 逆にメモリのレイテンシが重要な用途ではネットワークもレイテンシが重要な場合が多いハズ。 両者でバンド幅とレイテンシの必要性が逆転しているアプリというのはかなり特殊な用途に限られると思う。)

逆にレイテンシは重要で、この点ではハードウエアに短縮のための資源を投入したり、OSのレイヤを薄くする工夫が必要だろう。 おそらくは多段クロスバかファットツリーあたりではないだろうか?

また、総和計算のためのツリー結合網は絶対に必須なように思う。 例えばLINPACKといった用途を想定した場合、 総和計算部分ではネットワークのバンド幅は必要ないはずで、逆にレイテンシは極端に重要性が増す。 従って、対策としてはツリー結合網はベストマッチであると思う。 BlueGene/LはLINPACKではツリー結合網のレイテンシ優位性で3Dメッシュの不利を大きくカバーしていると思われるからだ。

もっとも、お互いに補完し合う用途を考えればアクセラレータ付きスカラ機側にはバンド幅系のハードウエア資源は不要だが、 一時は単独案だったわけだから、ある程度のバンド幅をメモリにもネットワークにも与えていたと考えるのが妥当かもしれない。 単独案同士のぶつかり合いとなれば、ベクトル機側はByte/FLOPの低いアプリでのコストパフォーマンスを、 スカラ機側はByte/FLOPの高いアプリでの実効効率を改善しなければならないからだ。

しかし、当サイトのいつもの主張によればByte/FLOPの高いアプリでの実効効率改善は 結局の所メインメモリのバンド幅改善に頼らざるを得ないと思う。 つまり、それはSMP方式を放棄せざるを得ないということだ。 複合機を前提としない段階ではSMP方式を放棄していた可能性は高いと思う。

最終案は複合機であるそうだから、Byte/FLOPの高いアプリはベクトル機側が担ってくれるから、 最終案の構成ならばスカラ機側はSMP方式でも問題は少なそうに思える。 LINPACKやMDのようなByte/FLOPの低いアプリに特化するなら、 SMP方式にしてメモリコストを抑制し、その分をノード数の増加につぎ込んだ方が良い結果を出せると思う。 しかし、単独機案時代の構成を引きずって非SMP構成だったりすると、ベクトル機側とバッティングする部分が増えてしまう。 このあたりの調整がうまく行われているかどうかが次世代スパコンのキモだという指摘は プロの先生のサイトでも指摘されていたが、この見解には当サイトも同感だ。

ともあれ、演算性能面をアクセラレータが担うとすると、スカラ機側がBlueGene/L的な超並列方式だと 長所短所がバッティングする部分が多くて効率が悪い構成となってしまう。 アクセラレータの性格から見て最も対照的な性格を持つプロセッサはベクトル機だが、富士通案だとするとベクトル機はあり得ないから、 この部分は同社のフラッグシップたるPRIMEPOWERをベースとしたものになるのではないだろうか?

なお、LINPACKベンチマークはこの手のアクセラレータが最も得意とする所であり、 密行列積計算はレイテンシが重要でメモリのバンド幅はあまり必要ない。 従って、最終案が複合機ということはByte/FLOPの高いアプリはベクトル機側が担ってくれるわけで、 アクセラレータとスカラCPUの演算性能はかなりアクセラレータ側に偏った方式にするのが妥当であろう。 従って、この点(演算性能の配分比)だけはTUBAMEシステムとはかなり異なっていると予想される。

と言うわけで、こちらも公開情報から当サイトの予想が外れていたことを素直に認めた上で、下記のように予想を修正してみた。

☆紆余曲折の複合機案。   
と言うわけで、日本でスパコンを製造しているすべてのベンダーが一致協力してのプランとなったわけだが、 もちろん一枚岩というわけではない。それは最初からアクセラレータ付きスカラとベクトルの複合機案だったわけではなく、 3機種複合→単独機2案のコンペ→2機種複合機という複雑な変遷を辿ってきたことからも容易に想像できる。

問題は機種間のFLOPS値の配分である。 当サイトはベクトル機で10PFLOPS級は出来ないと思っていたが、 一概にそうでも無さそうなのでここで予想を修正してみる。

まず、予想の前提条件だが、2案コンペの時代に巨大単独機案として結論が出せなかったことからして おそらくはスカラ、ベクトルの重要度はプロから見たらほぼ互角ということだろう。 すると、予算的な配分は両者でほぼ互角が妥当という事になる。 (何を持って平等な配分とするか...の基準は予算だけではないとは思うけれど。)

一方、数少ない価格データによればベクトル機はスカラ機の3倍強位価格が高いから、 予算がほぼ同額だとすると理論ピーク性能は1:3位でスカラ機側が高くなると思われる。(ただし、スカラ機側にアクセラレータが無い場合。) そして、スカラ機側がアクセラレータを使用し、アクセラレータ側のFLOPS値の配分が高いとすると、 スカラ側はさらに数倍のピーク性能を持つだろうから、そうするとピーク性能比で1:10位ではなかろうか?

一方、LINPACK性能で10PFLOPSが目標とのことであるから、効率を60%位(今はスカラでも80%位行くが、なんせ規模がでかいので低めに見ておく。) とすると理論ピーク性能は16PFLOPS強といったところである。 しかし、理論ピーク性能比でベクトルとスカラで大きな違いがあると仮定すると、 LINPACKのような単一アプリを複合機全体でロードバランスさせるというのは手間がかかる割に性能向上に寄与しない。 ここはスカラ+アクセラレータ側にスパッと割り切るのも一つの考え方かもしれない。 (単一アプリのロードバランスを複合機で取る手間よりも、スカラ機側の理論ピーク性能を1割上げる方が楽だと思う。)

マルチフィジクス、マルチスケールのようなアプリを使う場合は複合機はメリットがあるが、 LINPACKなどの単一アプリの場合には逆にデメリットばかりが目立って良いところがないという短所もある複合機ではある。 (実アプリでいかに性能を出せるかどうかが問題であり、世界一のタイトルに目を奪われるのは本末転倒だろう。 だから、LINPACKで世界一を奪取する事にはあまりこだわらないで設計した方が良いと思う。 これは国民受けという意味では危険な賭けだが、アーキテクトの設計問題というよりは本来国民の側が評価の知的レベルを上げるべき問題だね。)

一方、平等な配分を理論ピーク性能を基準として考えると、 ベクトル機は価格と実効効率が高いから実質的にはベクトル機に多くを配分した構成となる。 この場合は、ベンチマークで両機種を一体として動かす必要性が生じるから、 ロードバランスという意味ではソフトウエア開発の比重がかなり上がると思う。 チャレンジングではあるがリスクも大きい方法だろう。

また、両機種の結合方法だが、先ほど紹介したスパコンの専門書では、複合機の場合の両者の結合の程度に応じて ハイブリッドコンピューティング(ベクトル-スカラ間は密結合)と ハーモニックコンピューティング(ベクトル-スカラ間は疎結合)という概念が解説されているが、 ファイルシステム経由ということはハーモニックコンピューティングでもかなり疎な結合に分類できると思う。

ベクトルとスカラの結合部分がネットワークによる密結合ではなくファイルシステム経由の結合となっているということは、 両者の結合は自動的に疎結合という事になる。 (元々がアプリのByte/FLOPの高低で使い分けるという考えのようにも思える。)

ツギハギとは言わないまでも、元々が単独機案だったものを複合機として統合したわけだから、 再設計が必要な密結合は時間的制約から不可能だったのではないかと推測される。

ただし、これが悪かったかというと、当サイトでは元々ハイブリッドコンピューティングという複合機を想定してこなかったので、 これはこれで違和感はない。なぜならば、当サイトの考えでは別ノードでスカラとベクトルを密結合するハイブリッド機を作るくらいなら、 地球シミュレータのような構成のノードをスカラプロセッサ+ベクトルアクセラレータの2チップ構成で作った方が システム全体での整合性が取りやすいと考えていたからだ。

複合機の場合、機種間の結合は絶対に密結合でなければならないが、それはハードウエア的な密結合と言うことを意味しないと思う。 「密」とは各機種での演算結果の相互利用性が「密」と言うことであって、 物理的意味を伴わない演算途上の数値を機種間でやりとりするようなケースはかなり少ないと考えているからである。 (と言うわけで、当サイトが考えてきた複合機はこの専門書の分類で言えば無条件でハーモニックコンピューティングを指していた事になる。 ハイブリッドコンピューティングに相当するものは最初から頭になかった。)

今回の複合機という選定決定を見て思うことは、スパコンの用途が二極化しているのではないかという印象を感じたことだ。 つまり、従来から演算需要がある流体分野のようにByte/FLOPの高いアプリが求めるスパコンと、 近年演算需要が伸びているMDのようにByte/FLOPの低いアプリが求めるスパコンとでは理想像が乖離しており、 だからといって両者の中間のByte/FLOP領域にはおそらくポッカリと演算需要の少ない領域として穴があいているのだろう。 各種スパコン用アプリをByte/FLOPで分類したら、おそらくは正規分布ではなくふた山の分布をしているのではないだろうか?2)

ちなみに、どのようなアーキテクチャのCPUを設計したとしてもハードウエアとしてのByte/FLOP値は現在の技術では一定値となる。 しかし、ハードウエアとしてのByte/FLOP値が高いハードウエアでByte/FLOP値が低いアプリを実行すればコストパフォーマンスが悪化し、 ハードウエアとしてのByte/FLOP値が低いハードウエアでByte/FLOP値が高いアプリを実行すれば実効効率が低下し見かけ倒しの性能しか出ない。 それが高かろうと低かろうと、アプリが二極化していると必ずどちらかには合わないわけだ。

この問題を解決するのは非常に難しいと思う。

当サイトでは以前余談で書いたとおりハードウエアのByte/FLOP値を再構成できる動的再構成回路が可能かどうか考えてみたがダメだったし、 Byte/FLOP値が低いアプリとByte/FLOP値が高いアプリをSMTで同時実行して、平均値としてのByte/FLOP値を ハードウエアのByte/FLOP値に近づける事で効率を改善しようなんて考えたこともあるが、いろいろと考えたあげく どれもこれもアイディア倒れでなかなか上手くはいきそうもないという結論になった。 この問題はプロですら悩んでいるくらいだから、所詮シロウトではまともなアイディアが湧かないのも当然ではあるが... (どう考えても上手く行かなさそうなので文章として書いていないだけ...という、へたれアイディアなら結構あるのだけどね。)

だったら、それぞれに適したアーキテクチャを作って両者を緩やかに結合するというのは現状では悪くない発想に思える。 一つのアプリを高速に実行するために複合化するというアイディアはメリットだけではなくデメリットもあるという話を ここで書いたが、マルチフィジクスやマルチスケールなアプリでは複合機として使用し、 そうではない従来型のアプリではそれぞれ得意なアプリで別個に使用すればよい。

また、ハーモニックコンピューティングなら両機種を結合するネットワークは物量爆発が発生しないので、 ハイブリッドコンピューティングに比較してネットワークのコストアップも最小限で抑制することも出来る。 巨大単一機の場合はハードウエアのByte/FLOP値によって見捨てるアプリが出てくるので、 汎用機としては決断しにくいというのは理解できる考え方だ。

また、最終案はスカラとベクトルの複合機となっているが、スカラ側のアクセラレータはある種の専用機であり、 演算性能がアクセラレータ側に偏っているとすればそれは以前当サイトが ここで示した複合機としてのベスト案であるベクトル−専用機複合案に近い形式でもある。 (スカラの演算性能がアクセラレータと大差ない場合は予想は外れている事になるが...)

唯一の心配事項だが、新車の開発なんかがまさにそうなのだが、 合議制で妥協の産物として決まった設計はほとんどのケースで大失敗に終わっているという事実だ。 最終案が「複合機が次世代スパコンとしてはベストな構成である。これしかない!」という信念に基づいて決定されたのならば問題ないだろうが、 ベクトル機案とスカラ機案が一歩も譲らず、その結果妥協案として1/2スケールのスカラ機、ベクトル機がそれぞれ別個に作られて、 複合機がそれを正当化するお題目に使われていたりすると間違いなく計画は失敗に終わるだろう。 このような場合、肝心のマルチフィジクス、マルチスケール問題で性能が出せなくなるからだ。 (当サイトは次世代スパコンには大いに期待しているので、是非ともそのようなことにならないようにお祈りしたい。)

☆正統派の勉強は脳トレより効く。   
と言うわけで、専門書で勉強した新たな知識と公開情報の結果から、予想を修正してみたわけだがどうなのであろうか?  以前の予想はかなり間違っていたわけだが、 勉強の成果が出ているかどうかは箇条書きにした予想が当たっているかどうかでわかるわけだね。

今年は年頭挨拶でまじめに勉強をしてみる事を目標に掲げたので、 ウソにならないようにまじめな本でスパコンの勉強をしてみた。 トリ頭の脳みそに少しでもシワが増えるようにお祈りしているところだ。

ちなみに、将棋の方はと言うと東大将棋4に勝ったことから、早速ボナンザにチャレンジしてみた。 同様に居飛車穴熊戦法でボナンザに挑むも...6八角に2二飛車ですか...ふぅ。 さすがに棋書で振り飛車側が悪いと書いてある手は指してこないね。

渡辺竜王でさえ手こずった位だから当然とは言え、またも連敗街道まっしぐらである。3) 何事にも上には上があると言うことで、将棋も、スパコンの勉強も(当然、本業の材料開発も) さらに精進せい!という事だね。

予想というのは後講釈と違って書き手の実力がハッキリと現れる。 (今回のように外れると恥をかくわけだが...) 特にスパコンは、ロケットや加速器と同じく、いつの時代でも最先端科学の集大成である。 これを緻密に洞察できる実力が身につけば、脳トレなんかとは比較にならない本物の脳みそトレーニングになるだろう。

今年の目標は、脳みそのシワあとプラス3本だ。



1)
この専門書、途中まで読んで、とあるページで思わずのけぞった。 (何にのけぞったかはあえて書きませんけど。でも、ちょっと嬉しくも恥ずかしい。)

ちなみに、今回はこの本をネタにしたわけだけれど、 比較的ベクトル機に好意的という点で見解が似ているとは言え、当サイトは決して回し者ではありません。(笑)

2)
もし仮に正規分布しているなら、分布をアプリ毎の演算需要で重み付けして その中心値のByte/FLOPでハードウエアを設計するのが妥当だと思う。なので、この場合はあまり悩む必要がない。 ふた山分布の場合にこの方法でハードウエアのByte/FLOPを決めると、中心値が空白地帯になるのでどちらの用途にも中途半端な最悪マシンができあがる。

3)
本当は一応1勝しているのだが、これはボナンザのバグと思われるので勝ちとは認識していない。

序盤、手損でボナンザが角交換の上に馬をタダで作らせてくれて、しかもその後に角銀交換の駒損を仕掛けてきた上に、 その角がタダで馬になった。常識では考えられない悪手3連ちゃんでボナンザ自滅である。 馬の守りは金銀3枚と言われるが2枚馬の鉄壁の守りが完成したわけで、 後はジワジワと中央から厚みで押していけば放っておいても勝ちが転がり込むわけだ。 実際、ボナンザに対して王手すら一度もしていないのに、しばらくしてボナンザ投了。 (証拠としてボナンザ自滅の棋譜を貼っておきます。拡張子.csaのままDLしてボナンザで読めばOK。)