どの分野の開発難易度が低いのか?(最新HPC事情に思うこと。)   

2011年11月13日



☆天文マニアからのお誘い。   
まずはいつもの余談から...(と、ようやく書き続けられるようになった今日この頃。)

資格試験が終わった関係で友人からもいろいろお誘いのメールが来るようになった。 で、今回は天文マニアの友人に誘われて月光天文台へ。 場所は三島と熱海の中間位になる田方郡函南町。 20cm望遠鏡で木星観測がメインなのだそうだ。

この月光天文台、天文台だけではなく化石の博物館もあって、 子供連れでやってくる家族も結構ある。 当サイトも説明員による化石の説明は興味深いと思った。

資格試験も終わり、天文マニアの友人に誘われて月光天文台へ
20cm屈折望遠鏡で太陽と木星を観察させて頂いた。

もちろん主題は天体観測で、今回は昼間が太陽の黒点、夜は木星。 ただ、残念ながら現在は歴史的に黒点が少ない時期なのだそうで、 下の写真の通り黒点は小さな点が一つだけだった。

通常、黒点は11年周期で増減するはずであるが、 例外的に黒点が長期間ほとんど発生しなかった期間が過去2回あるのだそうで、 今回はおそらく3回目の異常事態になるだろうとのこと。

ちなみに、黒点は太陽活動が激しいほどたくさん観察されるのだそうで、 黒点が少ない時期が周期を越えて発生する時期は歴史的に異常冷温期になる可能性が高いのだそうだ。 つまり、地球温暖化現象と相殺される形になっており、 もしこの現象がなければ温暖化の影響はもっと派手に発生していただろうとのこと。 我々人類は今のところ天運に恵まれているというわけだね。

今の太陽は歴史的に黒点の少ない状態なのだそうだ。
天体観測だけではなく、富士山の夕景もまだ美しかった。

ちなみに、PCマニアである当サイトにとっては、天文観察も良かったけれど富士山の夕景の美しさもなかなかグッド、 また、三島市街の夜景もまたグッドでした。久しぶりの癒し週末であった。

☆明暗を分けた日米HPC事情。   
と言うわけで本題へ。今回は久々のスパコンネタ。

スパコンの話題と言えば、良い話はやはり「京」の世界最速奪取であろう。 日本のスパコンが世界最速になれるかどうかはかなり心配されていただけに、 予定処理能力の完成前に設置途上でのTOP500挑戦はよくよく考えた離れ業。 これは作戦勝ちと言っても良い。

しかも、以前は世界一になれるかどうかさえ疑われていたのであるが、 実際には2期連続の世界一が奪取できそうな雰囲気。 次回も世界一ならば当初の想定通りの製造計画日程でも世界一だったわけで、 建設途上でのTOP500挑戦という離れ業無しでも正攻法でトップに立てたわけだね。 (発表直前だ。)

一方のアメリカは逆に天運に見放されたようで、 BlueWaterが大失態の撤退表明。 目標性能が達成できないことが明らかとなって、 無理に達成しようとすればさらにコストが増大。 結局、設備投資全額返済となってしまった。 (過去にNECもベクトル機の京からの撤退を表明し問題となったことがあるが、 NECの場合は計画段階での撤退であり、製造中のドタキャンとは事情が異なる。)

今回の撤退は、当サイト的にはCPUを非HPC用途に設計しすぎた点が 他の部分に技術的な負担をかけてしまったことが要因だと推測している。 つまり、サーバー用途用にキャッシュを増やし、 そのHPC用途における効果の薄さを高クロック化でカバーしようとした結果、 発熱が大幅に増えて冷却システムの技術的課題を増やしてしまい、 温度上昇による信頼性の低下が発生して巨大システム化で失敗したという推測である。

実際、CPUそのものに基本的な問題があったわけではなく、 BlueWaterほど大規模ではないサーバーシステムでは問題なく販売が行われている。 つまり、今回の問題点はTOP5001位を狙うレベルの超大規模システムの場合のみの問題点と考えられる。

この問題は、今までアメリカが市場を席巻してきた「コモディティー用途開発の流用」 という方向性がTOP500首位レベルのHPCでは通用しなくなりつつある事を意味している可能性には注意が必要だと思う。 PC用途や通常のサーバー用途での信頼性でOKという設計では 京レベル以上のHPCを構築することは難しくなりつつあり、 その結果、PC用途では過剰となってしまうような高信頼性対応がHPC用途プロセッサに要求されつつあるように感じる。 つまり、信頼性面からはコモディティー化戦略が終焉を迎えつつある可能性があるわけだ。

これをコモディティー向けCPUで達成しようとすると、 演算途上で一部のCPUが壊れても自動的にシステム停止を回避し、 データ損傷のみの場合は再計算を、ハードウエアの損傷の場合は 代替システムの稼働が可能なシステムを構築しなければならない。 だが、今やPCやタブレットではこのような高機能信頼性をパーソナルユースのCPUに取り込む必要性がないから、 (こんなコア数のシステムを個人で使用する可能性は皆無である。) CPUのコア内部でこのような故障復帰機能をオンダイで実装することは サーバー用途でしか考えられないことになる。 しかし、そのサーバー用途でも全CPUを単一ジョブで使用するHPCと、 それぞれ独立した複数のスレッドで使用するサーバーでは要求性能も異なるだろう。

要するにHPCの高性能化をコア数増大という単純な手法で行ってきた結果、 HPC自身が最大の信頼性を求められる時代になってしまった。 このため、高信頼性維持コストのコモディティー用途による吸収が難しくなりつつある時代を 迎えてしまったということだと思う。

当サイトは、HPC用途CPUに対しては単純に高FLOPSを狙うだけでは用途が限られる点を指摘してきた経緯があるし、 京のコア予想では性能よりもコストや消費電力のトータルバランスを考えてクロックやキャッシュ容量を 意図的に抑制する方式になるだろうと予想してきた。 しかし、残念ながら信頼性維持が最重要項目になるとまでは予想できていなかった。

今回の京の成功とBlueWaterの撤退は、今後のHPC開発においては信頼性問題が最大要因になる事を示していると思う。

☆HPC用途でコスト負担することがどんどん難しくなっているが...   
それ以外の話題では、富士通からはポスト京の次世代HPCの発表が、 また、NECからは新型ベクトル機の発表が行われた。

京の時のベクトル機撤退表明に関して「NECは開発コスト負担に耐えられず ベクトル機開発自体から撤退するのでは?」という最悪の状況をも考えていたので、 NECの新型ベクトル機の発表は当サイトにとって嬉しい誤算であった。

また、おもしろかったのは今回のベクトル機では開発方針の大幅変更が行われたことである。 この開発方針の変更に関しては当サイトの意見と一致する方向と異なる方向の2種類があることがおもしろい。

当サイトの考えと意見が一致するのは、単一コア内部に全機能を搭載してワンチップ化を目指すという方向性だ。 これは消費電力抑制には必須の項目であり、当サイトの過去の意見と完全に一致する。 一方、コア内部にキャッシュを搭載するという方式は当サイトの見解とは不一致だ。

当サイトと意見が一致する部分は置いておいて、ここで一致しない部分を考えてみよう。 一致しない理由はコスト対策として性能低下を承知の上でやっている事だからだと思う。 まず、ベクトル機の優位性は高いB/F比にあるが、これは1.0まで低下している。

もちろんこれでもスカラ機よりは良好なのであるが、 この優位性でコスト負担をカバーするためにはB/F比の高さがコスト負担を超えなくてはならない。 そこで、NECはキャッシュを付けることでメインメモリのバンク数を減らしてコスト対策しているのでは? という予想をしている。

仮にこの予想が正しいとしてではあるが、これは正しい方向性なのであろうか?

ベクトル機の場合は、バンク数を多く取る目的には2つあって、一つは先ほど述べたB/F比アップ。 もう一つはメモリレイテンシの吸収だ。 この場合は、従来の手法に従えば、必要なバンク数はレイテンシ吸収の目的の方が強力に必要となるハズである。 なぜならば、単純計算ではバンク数はメモリアクセスレイテンシ分だけ必要だからである。

この場合だが、キャッシュを機能させる事ができれば理論上はバンド幅分まで減らせるはずである。 実際、GPGPU等ではバンド幅は大きいがバンク数は小さいので、 このあたりをかなり詳細にソフト側から詰め込んでいるようで、結構良い成果も出てきている。 つまり、バンド幅は維持するが、バンク数はあきらめるという事で、最大のメリットをなるべく失わせることなく コストを下げようという方向性なのだろう。

だが、もともとコモディティーであるGPUはダイの開発コストを量産製品で吸収できる一方で、 新規参入であるが故に過去のアプリを動かさなければならないという問題点が相対的に少なくてすむ。 これは一見すると優位な条件であるのだが、従来のアプリを改良・最適化しながら使っている ユーザーから見れば壁が高すぎるのだ。

アプリの対応というのは開発の難易度がケースバイケースで、 従来アプリの抜本的改良が十年以上も進んでいない分野だって結構ある。

一つ例を示してみよう。 それは地球シミュレータだ。

地球シミュレータの開発開始時には、 CPUをベクトル型にすると言う意見は三好先生の強い信念があって成し遂げられたものである。 当時、海外だけではなく日本でもスカラ機優位説は多かった。 スカラ機で地球シミュレータを作り、低B/F比はアプリカバーすればよい。 このような意見は今日だけではなく当時ですら結構あった。

ところが同様な方針でスカラ型気象用コンピュータを作成したアメリカは、 地球シミュレータに大敗を喫する事となる。 過去、気象シミュレーション分野ではアプリで対応すればよいという意見も多かったが、 結果としてはソフトウエア障壁がハードウエア障壁よりも高かったのである。 (スカラ型を採用したアメリカは地球温暖化研究において地球シミュレータに大敗を喫したことは事実である。)

三好先生の方針はベクトル方式にすることでノード数を減らし、その結果システム全体での高効率と高信頼性を維持し、 また、ソフトウエア開発の障壁を回避しようというものであったらしい。

まぁ、このあたりの話は当サイトが書くよりも、 地球シミュレータ開発史という良くできた詳しい資料があるから、これを一読するのがよろしかろうと思う。 (そもそも、天才技術者クレイがベクトル機を生み出したのも、「It's the Bandwidth.」という言葉に象徴されるように、 低バンド幅対応の難易度の高さを示したものであったのだからね。)

要するに、地球シミュレータは高B/F比により実効コストパフォーマンスでスカラ機を上回っていたとは言え、 今日でもベクトル機は「アプリ開発による時間の遅れをハードウエアコストで買う。」という、 時間を金で買う状況になっている分野は結構あると思われる。

と言うわけで、当サイトはアプリ対応の時間感覚を考えた場合は、 その難易度から考えてキャッシュ採用によるコスト削減という方向性が有効になるのには もう少し時間がかかるのではないかと考えているのだが... これが難易度が低くて簡単って話ならば、PC用途におけるマルチコア化戦略が今日のように破綻する事は無かったわけだしね。

もっとも、いくら売れても赤字では意味が無いと言われればその通り。 開発・製造コストをいかに下げるかは、ベクトル機の生き残りをかけた戦いなのは間違いない。