情報処理, Vol.41, No.7 (2000.7)
インタラクティブ・エッセイ
これでいいのか? 日本のスパコン
朴 泰祐 ／ 筑波大学 電子・情報工学系/計算物理学研究センター
概要
スパコンの世界は市場原理で動こうとすると無理がある。
米国のスパコンが upward-scalability を基本に作られているのに対し、
日本のそれは downward-scalability を基本に作られている。
これはベクトル機としてやむを得ない条件であり、
最大規模のマシン構成は良いが、エントリモデルが高価すぎる。
何らかのプロジェクト指向でスパコン開発を続けること、少なくともそれを続けられ
る土台を継続的に持つことは、日本が世界に誇る HPC ハードウェア技術を存
続させるために必要なことである。一旦、研究開発が中止されれば、そのキャッ
チアップは 10年やそこらでは不可能である。このような状況に対し、日本の
ベンダーと政府は昨今の不況にめげずに前向きに対処してほしい。
大学や国立研究所は全力でそれをバックアップし、産官学共同で日本の優れた
ハードウェア技術を守っていかなければならない。
TOP500
「スパコン」という言葉は実はあまり好きではないが、紙面節約と習 慣化された言葉ということで、敢えて使おう。先日、今年上半期のいわゆる TOP500リストが公開された (http://www.top500.org) 。 これは連立一次方程式の直接解法を基本とし たLINPACKベンチマークの公式結果から、世界の高性能コンピュータの上位500 位をリストアップしたもので、年2回公開されている。LINPACKにはいくつかの カテゴリがあるが、TOP500が対象としているのは「問題サイズはいくらでも大 きくてよく、とにかく実効MFLOPS値(Rmax)が大きい程よい」というものだ。 「そもそもLINPACKがマシン性能を表す正当なベンチマークか?」という長年の 疑問はあるにせよ、ともかく世界のハイエンドマシンの傾向を見るためのバロ メータにはなっている。
米国ASCI計画に後押しされたビッグ3マシン(IntelによるASCI Red、 SGI/CrayによるASCI Blue Mountain、IBMによるASCI Blue Pacific)が勢ぞろ いして以来、このところ上位3位は不動になっている。日本はといえば、1996 年下半期に筑波大/日立のCP-PACS、航空宇宙技術研究所/富士通のNWT、東大の 日立SR2201がトップ3を独占して以来、アメリカ勢に押され気味である。昨年 あたりまで何とかトップ10に1台入る程度だったが、今回の結果では高エネル ギー加速器研究機構と東大の日立SR8000がそれぞれ6位と9位に入っている。こ こでは「TOP500の上位に入るよう頑張ろう」なんていう話をするつもりはない。 ただ、日本のスパコン市場が下降気味になっ ていることに対し、もっと色々なソリューションを皆で考え、世界に名立たる 日本のスパコンにもっと頑張ってほしいというエールを送るつもりだ。
日米スパコンの違い
TOP500リストに対する各種分析の中に、「各メーカ製マシンの占める累積 FLOPS値」というのがある。500台のシステムをメーカ別に分け、それ ぞれが全体の何割を占めているかという分析である。ここでは米国製スパコン が大きな割合を占めており、日本製は苦しい立場にいる。この原因は2つある だろう。1つ目は「日本は米国製を買うが、米国は日本製を買わない」という、 不条理だが厳然たる事実である。日本で稼動している大規模なIBM RS6000/SP システムが上位にランクされていたりするが、その逆はない。もう1つは以下 に述べるアーキテクチャというか、スパコンへのアプローチの違いによるもの である。
この10年間の日米のスパコン情勢を考えると、アーキテクチャの面ではっき りとした差が出ているのが目につく。クレイの衰退以来、米国ではいわゆるベ クトル型計算機は姿を消しつつあり、一方日本ではハイエンドマシンの基本は 相変わらずベクトル型である。ここにTOP500の累積FLOPS値の差を 生む鍵がある。つまり、SGI/CrayやIBMが作っているマシンは基本的にワーク ステーション技術の延長にあり、いわば「小さなワークステーションをどうた くさんつなげていくか」という『スケーラビリティ』に基づく設計をしている。 これに対し、日本のスパコン３社のマシンは基本的に「ハイエンドシステムが 中心にあり、その小型版としてエントリモデルもある」という考えでできてい る。その結果、いわゆるミッドレンジに位置するシステムの価格や導入のし易 さに大きな差が生じていると考えられる。TOP500リストの中ごろから末尾のあ たりを見ると、この辺の差、つまりミッドレンジシステムのどれくらいを占め ているかがはっきり現れている。この辺が、IBMが圧倒的な「導入システム数 （ノード数ではない）」を誇っている1つの理由でもある。
一言で言えば、日本のスパコンは基本的に過去のベクトル技術の延長にあり、 良い面も悪い面も引きずっているが、結果としてハイエンドシステム中心になっ ているのに対し、米国性はローエンドからハイエンドまでのあらゆる階層に渡 り、総数的に有利になっている。
ベクトルを脱却すべきか？
スパコンのハードウエアで最もお金がかかっているのは実はプロセッサではなくメモ リである。プロセッサ内に高密度な演算装置を組み込むことは昨今の高集積化 技術によって可能となっている。それに対し、いかにしてプロセッサに大量の データを効率良く送り込むかという、いわゆるmemory wall problem はますます深刻化している。キャッシュに依存する米国型ソリューション は、これをキャッシュを有効利用するアルゴリズムやコンパイラの問題として 捉え解決している。しかし、これはアプリケーション依存の部分が大きく、必 ずしも万能ではない。日本のベクトル技術は、メモリのバンク化による高スルー プット化を礎に、大量のメモリトラフィックに耐えるようになっ ている。その意味で「問題への適応性」は日本側に軍配が上がる。
その意味で、キャッシュが有効に利用できるLINPACKは日本製スパ コンにとって非常に不利なベンチマークになっている。この点に着目し、日本 のメーカはベクトル機の「強力さ・タフネス」をもっとプロモーションすべき ではないか。今やベクトル技術は日本の「お家芸」であり、その有用性をもっ とアピールしなければならないだろう。
経済的情勢その他に押され、ベクトル技術を衰退させることは避けるべきで ある。大規模科学技術計算には、まだまだベクトルに頼らなければならない問 題が多くある。一旦ベクトル技術を捨ててしまえば、再びそれにキャッチアッ プするには長い時間がかかるだろう。今、世界に対して日本が計算機科学/工 学の面で優位に立っている技術を、おいそれと捨ててはならない。そのために スパコンメーカには歯を食いしばって頑張って欲しいという気持ちだ。
ただ、一つ注文したいのは小規模システムあるいはエントリモデルへの配慮 である。ある程度の大規模システムでちょうどペイするようなシステム構成 (例えば並列相互結合網）を想定すると、どうしてもローエンドシステムでは それがボトルネックになり、価格的に不利になってしまう。もう少し「間口の 広い」エントリが用意されていれば、ユーザも助かると思う。言うなれば、日 本のシステムには、大規模システムからの "downward-scalability" を 考えて欲しい。米国と比べ、ここが商売の分かれ目になっているように思えてな らない。例えば、少数プロセッサシステムではバンド幅が少し狭くコンパクト なスイッチがオプションとして選べる、なんていうのがうれしい。
クラスタでいいんですか？
話は変わるが、TOP500リストの移り変わりを見ていると、昨今はミッドレン ジを中心にクラスタシステム、特にPCクラスタの活躍が目立つ。極端な話、トッ プに君臨するIntelのASCI RedはPentium-II (III?) のデュアルプロセッサ構成 をネットワークで結合したものである。
では、クラスタシステムはハイエンドのスパコンになり得るか？賛否両論あ ろうが、ここでは敢えて「NO」と言っておこう。クラスタはミッドンジとロー エンドを支える非常に優れた技術である。が、やはりハイエンドをこれでまか なおうというのはかなり無理がある話だ。最大の問題はハイエンドシステムが 要求する大規模問題を本当にクラスタ向けにコーディングし、安定して動かす ことができるだろうかという疑問である。さらに、システムサイズの問題、 ネットワークケーブリングや、筐体の規模の問題もある。
スパコンを実際に使うということは、設置面積から始まり、安定運用させる ための管理、そして部品点数と共に急低下するMTBFの問題などをクリアしなけ ればならない。クラスタにそれを求められるかというと現状ではNOであろう。
最後はやはりお金の問題
現在のスパコン事情の苦しいところは、結局はやはりお金の問題である。世 界規模で見てもハイエンドコンピューティング（いわゆるHPC）市場は数千億 円と言われている。このただでさえ小さいパイを日米、さらに一部のヨーロッ パ企業で争うわけだから大変だ。 それに 加え、昨今の不景気を考えると、スパコン部門を何とかしてしまおうとメーカ が考えるのもわからないではない。しかし、前述したように日本の貴重なベク トル、あるいはスパコン技術は殺してはならない。
経済効果だけに任せていては火は消えてしまう。このためには、 国レベルでのバックアップが必要なことは言うまでもない。 現在の米国のスパコンだって、消え そうになっていたHPC技術の火に 対し米国政府が本腰を入れた結果の産物である。スパコン販売で不利になって いる日本のメーカを産官学の協力で助ける努力は必要である。
現状での最も明るい話は科学技術庁が行っている地球シミュレータ計画であ る。NECの協力の下でピーク性能40TFLOPS、アプリケーション性能5TFLOPSの大 型機（設置するのに体育館1つ分の建物が必要）が予定されている。このよう な超大型プロジェクトだけでなく、いろいろなレベルで産官学の協力を実現で きるプロジェクトが立ち上がって欲しい。日本の明るいスパコン未来のために。
(2000.6.16)
がんばるぞ、日本のスパコン
渡辺 貞 ／ 日本電気 ＮＥＣソリューションズ
日本のスパコン（実は、私もこの言葉は好きではありません）頑張れ とエールを送って下さっていることに対し、スパコン開発に長いあいだ携わっ てきたものとして、勇気付けられる思いです。
さて、ＴＯＰ５００をベースに「この世界」のサーベイをしていま すが、私はＴＯＰ５００で「この世界」の傾向を見ることには大きな疑問を 感じています。その理由をここでいろいろと述べる余裕はありませんが、次の 例を挙げるだけで十分でしょう。
ＴＯＰ５００のリストを見ますと、ドイツテレコムとかe-Bayなどがユーザと して載っています。ＴＯＰ５００に載るための性能指標であるLINPACKベンチ マークは浮動小数点演算を多用しますが、ドイツテレコムのアプリケーションが浮動 小数点演算を多用しているとは思われません。ＮＴＴやセブンイレブンの巨大 なシステムがこのＴＯＰ５００リストに登録されると、勢力分布は大きく変わ ってくるでしょう。日本のベクトルスパコンなどはかすんで見えなくなってし まうかもしれません。
次に、日米のスパコンの違いに言及されていますが、これについても一言付け 加えたいと思います。 旧クレイのベクトル機やＴ３Ｅなどが世の中から消えつつある現在、米国のほ とんどのスパコンは並列スカラサーバと呼ばれるものです。これらは、トラン ザクション処理やデータベース処理、ＣＡＤ用として製品化されたワークステ ーションやサーバを大規模化して科学技術計算用のスパコンとして用途を広げ たものと解釈することもできます。最近では、いろいろな開発用ツールが揃っ てきたとは言え、並列スカラサーバで、効率の良いソフトウェアを作るのには 大きな困難を伴います。極端なことを言えば、ハードウェアの開発は簡単に済 ませ、ソフトウェアの開発に大きな負担を強いるのが米国のマシンと言えるで しょう。
これに対して、日本のスパコンは伝統的に数値計算を主体とした科学技術計算 専用マシンということができます。従って、科学技術計算以外には利用できな いがために（トランザクション処理などにも使えるが効率が極めて悪い）、当 然のことながら、狭い市場にしか適用できません。しかしながら、数多くの科 学技術計算用アプリケーションは極めて効率良く走り、また、効率の良いソフ トウェアの開発も容易であるといえるでしょう。このような特徴を持つ大きな 理由としては、朴氏が述べているように、構造上は、メモリ周りの性能の違 いによるところが大きいからといえます。
さて次に、ベクトルを脱却すべきか、ということについて考えてみます。 これははっきり言って、ＮＯです。脱却すべきではありません。 ベクトル機の強みはなんと言っても、多くの科学技術計算において、並列スカ ラサーバよりもはるかに処理効率が上回るということにあります。
この大きな理由の一つは、ベクトル機のメモリ周りの強さにありますが、もう 一つ忘れてならないのは、ベクトル機はＳＩＭＤマシンだということにありま す。一度、ベクトル命令を取りだすと、あとはひたすら演算を繰り返せばよい という構造上の単純さがあります。それに対し、スカラプロセッサでは 高速化のために様々なアーキテクチャ上の工夫や コンパイラの最適化を行なっていますが、これにも限度があります。また、 スカラプロセッサを多数並列に並べたとしても、すべてのプロセッサへの均等 な負荷分散、プロセッサ間の同期オーバヘッドの削減、プロセッサ間通信量の 低減など、効率良いプログラミングのためには多大の労力を必要とします。
２０００年問題は終わりましたが、最近、米国においても「もう一つの２００ ０年問題」と称して、ベクトル機が使えないために、大規模科学技術計算環境 において、欧州や日本に遅れを取っているという記事を見かけます [1] [2] 。 私の知っている米国の研究者は「ここの計算センターはベクトル機から並列ス カラサーバに代わってしまった。我々はいきなりすべてのベクトル機用コード からＭＰＩによる並列コードに変えなければならなくなった。現場は大混乱だ」 と嘆いておりました。
最後にお金の問題です。 メーカとして、もっとも言いたいことは、世の中の風潮に惑わされることなく 「いいものはいい」とユーザが正しく評価し、適切な価格でシステムを導入し てくれることです。特にスパコンの場合は、政治的な働きによってシステムの 導入が決定されることがあり、適切なビジネスになっていないケースが多くあ ります。公正な評価によってシステムの導入がなされれば、健全なビジネス として、Grand Challenge分野の超ハイエンドは別として、永続的にスパコン を開発していくことが出来るでしょう。もちろん、ユーザ側の限られた予算の 中で要望を満たす適切なシステムとするためには、メーカ側では今以上にコス ト削減の努力が必要でしょう。ＣＰＵ周りの製造コストについて言えば、近い 将来、半導体技術の進歩により、ベクトル機と言えども、ＣＰＵはワンチップ となり、マイクロプロセッサを多数並べた並列スカラサーバと大きな違いが 無くなることは確実です。ところで、かつてセイモア・クレイと一緒にＣＤＣ ６６００を開発したニール・リンカーンはこんなことを言っています。
「回路設計やアーキテクチャはスーパーコンピュータと呼ぶ大きなパズルの ほんの一部分に過ぎない。スーパーコンピュータプロジェクトの実現性の重 要な制約条件は、機構部分、電力、実装、冷却条件である」 [3] 。話は脱線しましたが、真のスーパーコンピュータを開発しようとすると、ＣＰＵだ けでなく色々なところにお金がかかると言うことです。
メーカは市場拡大（ユーザを増やすように）にもっと努力すべきでしょう。 ハイエンドの開発がドライビングフォースとなって、それが下位の製品 につながる、そんなスーパーコンピュータは、特殊なアーキテクチャではなく 「汎用的」なものであり、且つコストも「安い」ものである必要があります。 ここが我々の腕の見せどころでしょう。
「日本には資源がない。日本の生きる道は科学技術立国だ」と戦後の教育で頭 からたたき込まれた古い（？）人間にとって、スーパーコンピュータの技術は、 コンピュータそれ自身の基本となる技術であるだけでなく、それを利用した科 学の発展、産業の振興にとっての基本となるものであることは疑う余地があり ません。そのためには、産官学の協力で、日本の明るい未来を開きたいと私も 願うものであります。
参考資料:(2000.6.19)
これからはクラスタでいいじゃん --- ソフト屋の独り言
松岡 聡 ／ 東京工業大学
まず、朴氏が述べられていたことに対しては、ほとんどの点については同意見 である。しかし、しかし、朴氏はそれらの観測に基づき、今後もベクトル技術 をHPCで捨てるべきではなく、クラスタはlow-end HPCのみに有 効だとしている。それは本当にそうだろうか? 筆者には、ハイエンドベクトル偏重主義は戦艦大和 を引きずった第二次世界大戦の旧日本海軍的いわば巨砲 (Big Iron)主義に映る。もはや時代は、機動性の高い超音速戦闘機 (Fast Commodity CPU)+空母(クラスタ)+哨戒システム(Software)に遷移してい るのだ。クラスタがハイエンドからローエンドまであまね くハイエンド(つまり、超高額)ベクトル機を今後駆逐していく技術的な妥当性 を述べていきたい。
今後のコモディティCPUの動向
筆者は別にベクトル技術が無用になると言っているので はない。そうではなく、スパコンにしか用いられないようなベクトルプロセッサ を作っても、総合性能でクラスタに凌駕されると述べているのである。むしろ、 PentiumIIIのSSE/SSE2, AMDの3D-Now!をみれば分るように、ベクトル技術はす でにコモディティプロセッサにDSP的な処理の高速化の切り札として、すでに 多く用いられている。
さて、PCに用いられているx86系のプロセッサの動向 について見 てみよう。 今後1、2年の内に浮動小数点の命令アーキテクチャが改善され、倍精度浮動小 数点演算性能がHigh-endのRISCプロセッサに匹敵するほど向上することになって いる。 また、チップメーカーの猛烈な競争によって、ミクロンルールの急速な微細化、 SOIやCopper interconnectなどの新技術の導入が行われている。これによりに GHzを超える急激なプロセッサクロックの上昇、およびロジック面積の相対的 減少による数値計算のピーク性能を維持するのに大変効果を発揮するオンチッ プ L2キャッシュの大容量化、が可能となる。 これらを総合すると、コモディティプロセッサの倍精度演算のピーク性能は、 2002年には8GFOPS以上であり、AMDの次世代プロセッサSledgehammerのように 浮動小数点ユニットが増える、あるいはベクトル演算が強化されれば10GFLOPS を軽く超えると予測される。よって、 2002年の時点で100node程度(数千万円程度)のクラスタでもピーク性能は軽く 1TFLOPSを超える可能性が高い。このような急速なコモディティCPUの性能向上 にベクトルの開発は追いつくのであろうか? コモディティプロセッサの市場規模 は数兆円であり、開発にはIntel, AMDなど各社莫大な数の人間が携わっていて、 さらに最新のプロセス技術が惜しみなく用いられ、 毎月のように新しいアーキテクチャやクロックの高速化が発表されているのが現 状である。これに対して、市場規模が1/1000以下の従来 型のスパコンがタイムリーに太刀打ちできるとは思えない。
It's the Bandwidth, Dammit----コモディティメモリバンド幅の劇的な向上
プロセッサのピーク性能が上昇しても、メモリバンド幅が向上しなければ、限 られたアルゴリズムしか性能向上しない。かのSeymore CrayはHPCアーキテクチャ の肝は "It's the Bandwidth"と言った。現状のPCで はメモリバンド幅は500MB/秒程度であり、一方スパコンはバンクメモリを駆使し て数Gバイト/秒以上である。
しかし、良く知られているように、この1、2年ではコモディティにおいてもメモ リバンド幅の急激な向上がある。一つはCPU性能の向上であるが、もう一つはグラ フィックス性能の向上に大きな需要がある。たとえば、最近話題になった PlayStation2はDual Channel DRDRAMを用い、メインメモリは3.2Gbyte/秒のバ ンド幅を持つ。最新のグラフィックカードで用いられているDDR-SDRAMでは、 メモリバンド幅6.4Gバイト/秒を達成している。 無論、これら高バンド幅のDRAMは 従来のマルチバンクメモリと比較し て、ランダムアクセス時のレーテンシが大きいなどの問題点があるが、連続ア クセスを行ったり、超高速なプロセッサ内の大容量L2キャッシュを使うなどす れば、その莫大なバンド幅を生かせるであろう。
6Gバイト/秒のメモリバンド幅を持つノードによって構成される100ノード程度のクラ スタの祖総メモリバンド幅は600Gバイト/秒である。これはかなりスパコンに近いとい えよう。
本当に高速ネットワークは必要なの?
ネットワークにおいても急激なコモディティ化は進行している。バンド幅の向 上が例えばEthernetでは10倍づつなので実感しにくいが、2000年後半にはCopper の1000Base-TXが一般的になり、スィッチも急激に安くなっている。同時に、 10Gbit Ethernetの実験も成功しており、さらに多少高くはなるが、Myrinet, Giganetなどの高速かつスケーラブルなインタコネクトも存在する。肝心のI/Oバ ンド幅も、PCI-X、さらにはInfinibandと、急激に向上している。
無論、ハイエンドのネットワークはカードや個々のノードのI/Oは比較的急激に 低価格になるが、スィッチはなかなか下がらないなどの問題もある。しかし、今 や 2年前は下手をすると20-30万円した100Base-Tのスイッチが8990円で売られて いる。コモディティのチップセットが開発されると、premiumを払わなくてはなら ない CPU以外の周辺機器は劇的に価格が下がる傾向がある。これぞコモディティ の恐ろしい性能向上のカギである。
さらには、本当にそれだけのネットワーク性能が必要かという観測もある。こ れは先のバンド幅の議論と多少矛盾するが、基本的にクラスタで並列化される数 値アルゴリズムは本質的に何らかの局所データに対する反復処理を行い、全ての データを通信しないものが多い。このような場合は、プロセッサの速度向上に対 して、 ネットワークの性能向上はそれほどでなくても大丈夫である。何故なら、単位 時間に処理されるデータ量の増加のオーダーに対して、通信量の増加のオーダー が低くなるからである。 もちろん、このような都合のよいアプリケーションだけではないが、 ワーストケースを考えてハイエンドネットワークに湯水のようにお金を注ぐの がスパコンの発想であり、それらをハードウェアではなくソフトウェアやアル ゴリズムで解決しようというのがクラスタの発想である。しかも実際、筆者ら の実験では、現状のプロセッサでは100Base-Tでも十分な性能を発揮するプロ グラムが少なくない。
じゃあ単にPCを並べればよいの?---It's the Software, Dammit!
では、今後ハイエンドPCを単に並べればスパコンにになるか? 答えはまだまだ Noである。朴氏も指摘しているが、現状のクラスタでは高度にチューニングされ たそれ向きのアプリケーションは高性能が得られるものの、ベクトルスパコンほ ど汎用ではない。 問題は、アルゴリズムやアプリケーションであり、超高速な大容量キャッシュ +ショートベクトル処理+粗粒度並列に対応した高性能数値アルゴリズムやアプ リケーション、ならびにその記述を容易にし、さらに利用や管理を容易にかつ ロバストにするソフトウェア技術である。
とどのつまり、今後のHPCは本当の大規模のものからローエンドまで、クラスタを 是とすればあとはソフトウェアの研究開発の問題となる。それゆえソフト屋の活 躍する場が出てくる。上記の問題は本質的にソフトウェア技術に対する大きなチ ャレンジであり、それを解決することによって、本質的に圧倒的にコストパフォー マンスが高く、かつテクノロジーカーブに載って性能が向上するクラスタがスパ コンを一気に凌駕することは目に見えている。米国ではすでにそれが起こってお り、この点において、わが国は圧倒的に立ち遅れている。 無謀なような主張に聞こえるかもしれ ないが、今後のHPCはハードウェアは「クラスタでいいじゃん」として、それ以外 の本質的開発はほとんど全て(アプリやアルゴリズムを含む)ソフトウェアに勢力 を注ぐのが肝要である。例えば数値アルゴリズム屋さんも、キャッシ ュマネージメントをうまく行うようなアルゴリズム以外は今後実用的には無価値 になる可能性を悟るべきであるし、アプリケーション屋さんもクラスタをターゲッ トとすることでユーザベースが圧倒的に広がるであろう。ソフトウェアと実用性 という観点からは、クラスタはようやく夜明けが始まった、といった感じである。
誤解していただきたくないのは、決してハードウェアのハイエンドの新しい技術 開発自身が無意味だと言っているのではない。そうではなく、それがコモディティ に降りてくるようなビジョンや作戦がなければ、所詮はコモディティの急激な速 度向上とコストパフォーマンスに負けてしまう、ということである。そこでは素 晴らしいハードウェアだけではなく、それに付随したソフトウェアの開発コスト も、コモディティに載っていないゆえ、回収できない。
おわりに: 地球シミュレータに勝てるの?
最後に、地球シミュレータに「勝つ」クラスタを考えると、2003年に仮に.10 ミクロン(.07ミクロンという話もある) に移行出来たとすると、その時点ではクロックは2.5GHz以上、また64bitアー キテクチャが主流になり、コモディテイでもより強力な浮動小数点やベクトル 処理とあいまって、単体性能は10-20GFLOPSを超えると考えられる。20GFLOPS とすると、ピーク性能比較では2000台で地球シミュレータに匹敵する。無論 実行性能は別問題だが、単にピーク性能ならば現状のASCI Redの1/5のサイズ で良いのである。 それがコモディテイの進歩の恐ろしさでもあり、それゆえそのソフトウェアが 重要になる。しかるに、ソフト屋の筆者がクラスタを構築する所以である。
[編集者注： 紙面の都合で、議論を裏付ける具体的なデータなどを大幅に削除 せざる得なかったことをお断りしておく。興味のある方はWeb上の完全版を 参考にされたい。]
(2000.6.20)
日本のスパコン、悪いのは君じゃない
関口智嗣 ／ 通商産業省 工業技術院 先端情報計算センター
朴先生はクラスタごとき積み木細工の安易な（知恵のない！）成金趣味的性能 至上主義を謙虚に批判し、スパコンアーキテクチャの行く末を憂いた。しかし、 問題はアーキテクチャだけに存在するのであろうか。ユーザ、センター、プロ ジェクトという周囲の環境から考え直してみたい。
頑張れスパコンユーザ
第１世代のスパコンユーザ（CRAY-1）や第２世代(CRAY-X/MP, S810, VP200, SX-2) からの筋金入りのユーザは、今でも実力・経歴とも尊敬に値するもので、 数々のシステムにおける逸話の語り部であったりする。
しかし、今のユーザはどうだ。９０年代に次々と導入されたスパコンが、ふる さと創生ではないが全国津々浦々に配備され、誰でもが気軽に触れるようになっ てしまった。修行なんて必要なし。手元のワークステーションよりちょっと速 いからというだけの理由でスパコンを使い回す。やっていることはスパコンの パソコン化、すなわち購入してきたソフトウエアをカパチョンとセットして、 時間のある限りそれと戯れている。これではまるでファミコンではないか。微 妙に違う入力データを加えては、答えを待つ。確かに、スパコンを使っている が、そこには工夫もない。 CPU時間じゃぶじゃぶな環境に甘えているだけ。こ のようなユーザには庶民的なクラスタでも与えておけば十分である。 スパコ ンユーザは困難なアーキテクチャ、気むずかしいソフトウエアを克服し、ピー クを目指して踏破することに生き甲斐を感じて欲しい。
ん、まてよ、クラスタやASCIなシステムはとある国の得意とする分野。そして、 スパコン用のファミコンソフトはほとんど輸入に頼っているもの。これは、日 本における産業基盤ソフトウエア、半導体・代替エネルギー・環境・新材料・ 薬物等の産業における設計・製造・実験などに計算科学的手法を取り入れたソ フトウエア、も輸入超過にして、技術の空洞化を誘発し、同時に日本が得意と していたスパコンアーキテクチャを壊滅的に葬り去る戦略かも知れない。
先進的ユーザ諸君、日本の産業技術の空洞化を救うのは君たちだ。早く目を覚 ましてくれ。工夫もしないで、スパコンとパソコンを比較して、性能の良否を 議論しないでくれ。せっかく、潤沢な計算資源をもらったのだから、スパコン の良い所、全部を使い切ってみてくれ。悩み多きベンダの歩みは遅くとも、計 算機屋と工夫をしていくことがこれからの日本のスパコン技術を育てるのだ。
頑張れスパコンセンター
日本のスパコンセンターって、実は難しい。確かにスパコン（今の定義によれ ば１００GFLOPS以上）を保有する計算センターは国立のものだけでも旧大型計 算機センターをはじめとして、科学技術庁研究所関連、通商産業省工業技術院 関連など２０を越える。これらの計算センターのうちほとんどは特定ユーザの ためのサービスであり、それぞれの企画・運営は良い意味で孤高を誇っている。
しかし、米国のスパコンセンターのリストラを見よ。米国ではNPACI(National Partnership for Advanced Computational Infrastructure) という全米仮想 計算基盤センターとしてサンディエゴスーパーコンピュータセンター(SDSC)を 中心に再構成を行った。実際の計算機は全米に分散配置されているが、これら を統一的に見せる仕掛けを作って、ユーザからはあたかも単一システムのよう に見えている。大学や国立研究所等で開発された萌芽的ソフトウエアやツール の中で実戦配備に役に立ちそうなものをThrust Areaとして数千万円規模の開 発費を渡し、成果物をNPACIに導入するという手法を用いている。これにより NPACI が主導的に「世の中にすぐに役立つ技術」を選定している。 これによ り、メタコンピューティング、グリッドといったセンター間やサイト間に跨っ た計算機利用技術も非常に現実的なものとして議論がされている。
翻って日本ではどうか。たとえば、筆者のいるつくば地域で高速ネットワーク を引いて、お互いのスパコンをちょこっとずつ時間貸し借りするような実証的 実験をしませんか、とある会議で提案した見たことがある。その反応といえば、 他のサイトに貸すCPU時間があることが会計検査院に指摘されると困る、セキュ リティが問題、あちこちのスパコン使っても面倒なだけ、と散々であった。ス パコンの有効利用して「何をやるのか」が重要なのであり、それを促進するセ キュリティ技術、ミドルウェアの研究と実証こそが重要な研究課題なのに、で ある。
しかし、これでは積極的に新しいネットワーク・ＩＴ技術の導入を図っている 諸外国との格差は拡がるばかり。少なくとも筆者の所属する先端情報計算セン ターは独立法人化に向けて積極的なビジネスを展開していくつもりだ。そうし ないと運営費が未来永劫保証されるものじゃない。通商産業省的には、今まで の限られたユーザばかりでなく、新規産業創出を企てる中小企業にもスパコン 利用機会の提供を与えることで産業基盤の強化をはかり、スパコン利用の実需 を掘り起こす必要があるのではないか。これで、高々数百億円といわれるスパ コン市場を拡大していくことができるのではないか。スパコン技術の独立採算 では赤字だそうだか、こうした市場拡大の努力をスパコンセンターも協力する べきではないだろうか。このことが、スパコンベンダの体力強化となり、セン ターにも世界に誇れる素晴らしいモンスターが導入されることになるだろう。
頑張れスパコンプロジェクト
ここ数年、IT技術の重要性の高まりとともに、未曾有のHPC技術への追い風が 国内外で吹いている。
これまで、スパコン大プロなどかつては独自のハードウエアを中心とし、その 回りのソフトウエア群を開発し、応用問題を載っけて完了というシステム開発 型のプロジェクトスタイルが典型的であった。しかし、ハードウエアやアーキ テクチャの詳細は非公開、世の中のトレンドを見ないソフトウエアは特殊仕様 で融通が利かない、人材がどこで育っているのかわからない、ということで、 プロジェクト終了後の波及効果がいまいち見えないのが常であった。今ではと てもはやらない。
スパコンプロジェクトに限らないが、米国の（とばかり言うのは気が引けるが） をモデルとしつつ、以下の提言をしたい。
(2000.6.20)
It's still the Bandwidth!
朴 泰祐 ／ 筑波大学 電子・情報工学系/計算物理学研究センター
スパコン話に予想以上の反応があり嬉しい悲鳴をあげている。渡辺氏・松岡氏・ 関口氏の各視点からの意見を面白く読ませて頂いた。そろそろこの話をまとめ なければならないが、実は紙面の都合上、各自の元原稿は大幅に短縮されて本 誌に掲載されている。WWW上の完全版 (http://www.ipsj.or.jp/magazine/interessay.html)の方に、より具体的なデー タや過激な(?)議論があるのでぜひお読み頂きたい。
結局「スパコンはやっぱりバンド幅」という結論は変わらないようだ。渡辺氏 の意見はもちろんのこと、松岡氏の意見も裏を返せばクラスタが適用できるの はメモリバンド幅を食わない、あるいはそれを隠せるアプリ、ということにな る(「コモディティのバンド幅は増えてるぞ」と主張しているが、まだまだ不 足)。スパコンに金がかかっているのはまさにこの点であり、SSEやらEmotion EngineのSIMD命令があっても「釈迦の掌」でしか動けない。掌を大きくするか、 少なくとも大きく見せる工夫が必要だ(本誌1999年9月号のインタラクティブ・ エッセイの中村氏の意見にも関係する)。結局は適材適所ということになって しまうかもしれないが、まだまだ当分はスパコンとクラスタの棲み分けは続き そうだ。また、スパコン技術のバックアップのためには単にメーカを後押しし てマシンを作らせるだけでは駄目、という関口氏の意見もよくわかる。単純な 「護送船団方式」ではない将来を見据えたプロジェクトは重要だろう。
日本が何らかの形でスパコン技術的に世界をリードして欲しいという思いは皆さ ん共通のようだ。限られた紙面ではこの程度のまとめしか書けないが、このテー マはまだまだWWW上で続いてほしいと思う。頑張れ、日本のスパコン！
(2000.6.22)