情報処理, Vol.41, No.7 (2000.7)
インタラクティブ・エッセイ
これでいいのか? 日本のスパコン
朴 泰祐 ／ 筑波大学 電子・情報工学系/計算物理学研究センター
概要
スパコンの世界は経済原理で動こうとすると無理がある。特に日本のそれは
ASCI 等のマシンが upward-scalability を基本に作られているのに対し、
downward-scalability (reverse-scalability) を基本に作られている、つ
まり最大規模のマシン構成は良いが、エントリモデルの入り口が高すぎる。し
かし、これはベクトル機としてやむを得ない条件でもある。とにかく、何らか
のプロジェクト指向でスパコン開発を続けること、少なくともそれを続けられ
る土台を継続的に持つことは、日本が世界に誇る HPC ハードウェア技術を存
続させるために必要なことである。一旦研究開発が中止されれば、そのキャッ
チアップは 10年やそこらでは不可能である。このような状況に対し、日本の
ベンダーと政府は昨今の不況にめげずに前向きに対処してほしい。もちろん、
大学や国研は全力でそれをバックアップし、産管学共同で日本の優れたハード
ウェア技術を守っていかなければならない。
TOP500
はじめに、本稿ではスパコンを保有する組織名やメーカ名が名指しでどんど ん出てくるが、それらの全ては客観的事実を述べるために挙げているのであり、 それ以上の意味は何ら含まれていないということを予めお断りしておく。これ は筆者が「H社」みたいな曖昧な表現が嫌いだからである。エッセイというこ とでお許し願おう。
さて、「スパコン」という言葉は実はあまり好きではないが、紙面節約と習 慣化された言葉ということで、敢えて使おう。先日、今年上半期のいわゆる TOP500リストが公開された [1] 。 これは連立一次方程式の直接解法を基本とし た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 システムが上位にランクされていたりするが、その逆はない（ドイツで日立の SR8000が5位に入っているが、これはヨーロッパの話）。もう1つは以下に述べ るアーキテクチャというか、スパコンへのアプローチの違いによるものである。
この10年間の日米のスパコン情勢を考えると、アーキテクチャの面ではっき りとした差が出ているのが目につく。クレイの衰退以来、米国ではいわゆるベ クトル型計算機は姿を消しつつあり、一方日本ではハイエンドマシンの基本は 相変わらずベクトル型である（日立は純粋なハードウェアベクトル機構から、 擬似ベクトルと呼ばれるソフトウェア指向に切り替えているが本質的にはキャッ シュに頼らないベクトル機とみなせる）。ここにTOP500の累積FLOPS値の差を 生む鍵がある。つまり、SGI/CrayやIBMが作っているマシンは基本的にワーク ステーション技術の延長にあり、いわば「小さなワークステーションをどうた くさんつなげていくか」という『スケーラビリティ』に基づく設計をしている。 これに対し、日本のスパコン３社のマシンは基本的に「ハイエンドシステムが 中心にあり、その小型版としてエントリモデルもある」という考えでできてい る。その結果、いわゆるミッドレンジに位置するシステムの価格や導入のし易 さに大きな差が生じていると考えられる。TOP500リストの中ごろから末尾のあ たりを見ると、この辺の差、つまりミッドレンジシステムのどれくらいを占め ているかがはっきり現れている。この辺が、IBMが圧倒的な「導入システム数 （ノード数ではない）」を誇っている1つの理由でもある。
一言で言えば、日本のスパコンは基本的に過去のベクトル技術の延長にあり、 良い面も悪い面も引きずっているが、結果としてハイエンドシステム中心になっ ているのに対し、米国性はローエンドからハイエンドまでのあらゆる階層に渡 り、総数的に有利になっている。
この他にも「最大のシステムを作ったときの大きさ」も比較すると面白い。 ASCIの巨大マシンの実装の様子などはWWWなどを通じて簡単に見ることができ る（ASCI Blue Pacificが何日もかけてどのようにインストールされたかは、 Webページ [2] に時系列で紹介されていて非常に興味深い）。例えば1 TFLOPSを 達成するために要する床面積を見てみると、IBMと日立に大きな差があるのが 一目でわかる。先日、ロスアラモスで次期ASCIマシンを導入するビルの建築の 様子を見たが、この工事のため深刻な駐車場問題が生じているそうだ。日本の 敷地面積事情を考えると、これは大きな問題だろう。つまり、日本のスパコン は日本の狭い国土にマッチしているといえる。
ベクトルを脱却すべきか？
スパコンのハードで最も金がかかっているのは実はプロセッサではなくメモ リである。プロセッサ内に高密度な演算装置を組み込むことは昨今の高集積化 技術によって可能となっている。それに対し、いわゆるmemory wall problem はますます深刻化しており、いかにしてプロセッサに大量のデータを効率良く 送り込むかが問題となっている。キャッシュに依存する米国型ソリューション は、これをキャッシュを有効利用するアルゴリズムやコンパイラの問題として 捉え解決している。しかし、これはアプリケーション依存の部分が大きく、必 ずしも万能ではない。日本のベクトル技術は、メモリのバンク化による高スルー プット化を礎に、ある程度の絶対的なメモリトラフィックに耐えるようになっ ている。その意味で「問題への適応性」は日本側に軍配が上がる。
その意味で、キャッシュブロッキングが容易に行えるLinpackは日本製スパ コンにとって非常に不利なベンチマークになっている。この点に着目し、日本 のメーカはベクトル機の「強力さ・タフネス」をもっとプロモーションすべき ではないか。今やベクトル技術は日本の「お家芸」であり、その有用性をもっ とアピールしなければならないだろう。
経済的情勢その他に押され、ベクトル技術を衰退させることは避けるべきで ある。大規模科学技術計算には、まだまだベクトルに頼らなければならない問 題が一杯ある。一旦ベクトル技術を捨ててしまえば、再びそれにキャッチアッ プするには長い時間がかかるだろう。今、世界に対して日本が計算機科学/工 学の面で優位に立っている技術を、おいそれと捨ててはならない。そのために スパコンメーカには歯を食いしばって頑張って欲しいという気持ちだ。
ただ、一つ注文したいのは小規模システムあるいはエントリモデルへの配慮 である。ある程度の大規模システムでちょうどペイするようなシステム構成 (例えば並列相互結合網）を想定すると、どうしてもローエンドシステムでは それがボトルネックになり、価格的に不利になってしまう。もう少し「間口の 広い」エントリが用意されていれば、ユーザも助かると思う。言うなれば、日 本のシステムには、大規模システムからの『リバース・スケーラビリティ』を 考えて欲しい。米国と比べ、ここが商売の分かれ目になっているように思えてな らない。例えば、少数プロセッサシステムではバンド幅が少し狭くコンパクト なスイッチがオプションとして選べる、なんていうのが嬉しい。(かつてIBM SP2には、ネットワークをHigh Performance Switchにするか、Ethernetにする かというオプションがあった)
クラスタでいいんですか？
話は変わるが、TOP500リストの移り変わりを見ていると、昨今はミッドレン ジを中心にクラスタシステム、特にPCクラスタの活躍が目立つ。極端な話、トッ プに君臨するIntelのASCI RedはPentium-II (III?)のデュアルプロセッサ構成 をParagonの名残のネットワークで結合したものである。これもLinpackだから、 という面はあるもののなかなか頑張っている。
では、クラスタシステムはハイエンドのスパコンになり得るか？賛否両論あ ろうが、ここでは敢えて「NO」と言っておこう。クラスタはミッドンジとロー エンドを支える非常に優れた技術である。が、やはりハイエンドをこれでまか なおうというのはかなり無理がある話だ。最大の問題はハイエンドシステムが 要求する大規模問題を本当にクラスタ向けにコーディングし、安定して動かす ことができるだろうかという疑問である。さらに、システムサイズの問題もあ る。ネットワークケーブリングや、筐体のコンパクトさなどを考えると、数千 ノードのクラスタ（それぐらいはないと太刀打ちできない）を安定運用するの はなかなか大変そうである。
スパコンを実際に使うということは、設置面積から始まり、安定運用させる ための管理、そして部品点数と共に急低下するMTBFの問題などをクリアしなけ ればならない。クラスタにそれを求められるかというと現状ではNOであろう。 繰り返すが、トップを狙わないマシンとしてはクラスタは非常に効率的だと思 う。（現在、TOP500の末尾はだいたい45GFLOPSぐらい。1GHzのAthlonのクラス タで充分挑戦可能ですよ、皆さん）
最後はやはりお金の問題
現在のスパコン事情の苦しいところは、結局はやはりお金の問題である。世 界規模で見てもハイエンドコンピューティング（いわゆるHPC）市場は数千億 円と言われている。このただでさえ小さいパイを日米、さらに一部のヨーロッ パ企業で争うわけだから大変だ（片や、日本国内のパチンコ産業は数兆円規模 だというのに）。計算機システムとしても、サーバ(ビジネス)系に比べ数値計 算系の市場は小さい(かつ、一般にユーザがお金を持っていない :-))。それに 加え、昨今の不景気を考えると、スパコン部門を何とかしてしまおうとメーカ が考えるのもわからないではない。しかし、前述したように日本の貴重なベク トル、あるいはスパコン技術は殺してはならない。何とか頑張ってもらいたい。
もちろん、経済効果だけに任せていては火は消えてしまう。このためには、 国レベルでのバックアップが必要なことは言うまでもない。ASCIだって、消え そうになっていたHPCN (High Performance Computing and Networking)の火に 対し米国政府が本腰を入れた結果の産物である。スパコン販売で不利になって いる日本のメーカを産官学の協力で助ける努力は必要である。
現状での最も明るい話は科学技術庁が行っている地球シミュレータ計画であ る。NECの協力の下でピーク性能40TFLOPS、アプリケーション性能5TFLOPSの大 型機（設置するのに体育館1つ分の建物が必要）が予定されている。このよう な超大型プロジェクトだけでなく、いろいろなレベルで産官学の協力を実現で きるプロジェクトが立ち上がって欲しい。日本の明るいスパコン未来のために。
参考資料:(2000.6.16)
がんばるぞ、日本のスパコン
渡辺 貞 ／ 日本電気 ＮＥＣソリューションズ
朴先生、日本のスパコン（実は、私もこの言葉は好きではありません）頑張れ とエールを送って下さっていることに対し、スパコン開発に長いあいだ携わっ てきたものとして、勇気付けられる思いです。
さて、先生は「ＴＯＰ５００］をベースに「この世界」のサーベイをしていま すが、私は、ＴＯＰ５００で「この世界」の傾向を見ることには大きな疑問を 感じています。その理由をここでいろいろと述べる余裕はありませんが、次の 例を挙げるだけで十分でしょう。
ＴＯＰ５００のリストを見ますと、ドイツテレコムとかe-Bayなどがユーザと して載っています。ＴＯＰ５００に載るための性能指標であるＬＩＮＰＡＣＫ は浮動小数点演算を多用しますが、ドイツテレコムのアプリケーションが浮動 小数点演算を多用しているとは思われません。ＮＴＴやセブンイレブンの巨大 なシステムがこのＴＯＰ５００リストに登録されると、勢力分布は大きく変わ ってくるでしょう。日本のベクトルスパコンなどはかすんで見えなくなってし まうかもしれません。
次に、日米のスパコンの違いに言及されていますが、これについても一言付け 加えたいと思います。 旧クレイのベクトル機やＴ３Ｅなどが世の中から消えつつある現在、米国のほ とんどのスパコンは並列スカラサーバと呼ばれるものです。これらは、トラン ザクション処理やデータベース処理、ＣＡＤ用として製品化されたワークステ ーションやサーバを大規模化して科学技術計算用のスパコンとして用途を広げ たものと解釈することもできます。最近では、いろいろな開発用ツールが揃っ てきたとは言え、並列スカラサーバで、効率の良いソフトウェアを作るのには 大きな困難を伴います。極端なことを言えば、ハードウェアの開発は簡単に済 ませ、ソフトウェアの開発に大きな負担を強いるのが米国のマシンと言えるで しょう。
これに対して、日本のスパコンは伝統的に数値計算を主体とした科学技術計算 専用マシンということができます。従って、科学技術計算以外には利用できな いがために（トランザクション処理などにも使えるが効率が極めて悪い）、当 然のことながら、狭い市場にしか適用できません。しかしながら、数多くの科 学技術計算用アプリケーションは極めて効率良く走り、また、効率の良いソフ トウェアの開発も容易であるといえるでしょう。このような特徴を持つ大きな 理由としては、朴先生が述べているように、構造上は、メモリ周りの性能の違 いによるところが大きいからといえます。
さて次に、ベクトルを脱却すべきか、ということについて考えてみます。 これははっきり言って、ＮＯです。脱却すべきではありません。 ベクトル機の強みはなんと言っても、多くの科学技術計算において、並列スカ ラサーバよりもはるかに処理効率が上回るということにあります。もちろん、 例外はあります。
この大きな理由の一つは、ベクトル機のメモリ周りの強さにありますが、もう 一つ忘れてならないのは、ベクトル機はＳＩＭＤマシンだということにありま す。一度、ベクトル命令を取りだすと、あとはひたすら演算を繰り返せばよい という構造上の単純さがあります。スカラ命令は、単純な繰り返し演算でも、 データフェッチ、演算、ループカウント、分岐を繰り返すこととなります。ま た、命令実行のためには、当然のことながら、複数の命令フェッチもあること を忘れてはなりません。このような複数命令の実行において、パイプラインハ ザードを避けるために、Ｏｕｔ−ｏｆ−ｏｒｄｅｒ実行、プレディケーション、 レジスタリネイミング、投機実行など、さまざまなアーキテクチャ上の工夫や コンパイラの最適化を行なっていますが、これにも限度があるでしょう。また、 スカラプロセッサを多数並列に並べたとしても、すべてのプロセッサへの均等 な負荷分散、プロセッサ間の同期オーバヘッドの削減、プロセッサ間通信量の 低減など、効率良いプログラミングのためには多大の労力を必要とします。ア ムダールの法則から言っても、少数の強力なプロセッサによる並列化がもっと も効率の良いのは明らかです。
２０００年問題は終わりましたが、最近、米国においても「もう一つの２００ ０年問題」と称して、ベクトル機が使えないために、大規模科学技術計算環境 において、欧州や日本に遅れを取っているという記事を見かけます [1] [2] 。 私の知っている米国の研究者は「ここの計算センターはベクトル機から並列ス カラサーバに代わってしまった。我々はいきなりすべてのベクトル機用コード からＭＰＩによる並列コードに変えなければならなくなった。現場は大混乱だ」 と嘆いておりました。
また、最近、日本の某研究所に設置されたＬＩＮＰＡＣＫではほぼ同等性能の ベクトル機と並列スカラサーバの稼動状況を調べてみました。その結果、ＣＰ Ｕの使用稼動率はベクトル機が圧倒的に高く、平均のジョブの性能はベクトル 機ではＧＦＬＯＰＳオーダーであったのに対し、並列スカラサーバ上のジョブ の平均性能はＭＦＬＯＰＳオーダ−でした。これを見ても実際の環境ではベク トル機はかなり有効に使われており、この傾向はベクトル機が存在する限り、 近い将来、大きく変わるとは思われません。ベクトル機は物理や化学の研究分 野、企業の開発現場では有用なツールなのです。
最後にお金の問題です。 メーカとして、もっとも言いたいことは、世の中の風潮に惑わされることなく 「いいものはいい」とユーザが正しく評価し、適切な価格でシステムを導入し てくれることです。特にスパコンの場合は、政治的な働きによってシステムの 導入が決定されることがあり、適切なビジネスになっていないケースが多くあ ります。公正な評価によってシステムの導入がなされれば、健全なビジネス として、Grand Challenge分野の超ハイエンドは別として、永続的にスパコン を開発していくことが出来るでしょう。もちろん、ユーザ側の限られた予算の 中で要望を満たす適切なシステムとするためには、メーカ側では今以上にコス ト削減の努力が必要でしょう。ＣＰＵ周りの製造コストについて言えば、近い 将来、半導体技術の進歩により、ベクトル機と言えども、ＣＰＵはワンチップ となり、マイクロプロセッサを多数並べた並列スカラサーバと大きな違いが 無くなることは確実です。ところで、かつてセイモア・クレイと一緒にＣＤＣ ６６００を開発したニール・リンカーンはこんなことを言っています。
「回路設計やアーキテクチャはスーパーコンピュータと呼ぶ大きなパズルの ほんの一部分に過ぎない。スーパーコンピュータプロジェクトの実現性の重 要な制約条件は、機構部分、電力、実装、冷却条件である」 [3] 。話は脱線しましたが、真のスーパーコンピュータを開発しようとすると、ＣＰＵだ けでなく色々なところにお金がかかると言うことです。
メーカは市場拡大（ユーザを増やすように）にもっと努力すべきでしょう。そ のためには、先生の仰るように、裾野を広げる努力をもっともっとすべきでし ょう。ハイエンドの開発がドライビングフォースとなって、それが下位の製品 につながる、そんなスーパーコンピュータは、特殊なアーキテクチャではなく 「汎用的」なものであり、且つコストも「安い」ものである必要があります。 そうするとハイエンドは、「汎用的」で且つ「安い」ものであるがために、大 規模計算では性能が出ないと言ったジレンマに陥る可能性もありますが、そこ を解決するのが我々開発するものの腕の見せ所ということになるのでしょう。
「日本には資源がない。日本の生きる道は科学技術立国だ」と戦後の教育で頭 からたたき込まれた古い（？）人間にとって、スーパーコンピュータの技術は、 コンピュータそれ自身の基本となる技術であるだけでなく、それを利用した科 学の発展、産業の振興にとっての基本となるものであることは疑う余地があり ません。そのためには、産官学の協力で、日本の明るい未来を開きたいと私も 願うものであります。
参考資料:(2000.6.19)
これからはクラスタでいいじゃん---ソフト屋の独り言
松岡 聡 ／ 東京工業大学
なぜ我は大規模コモディティクラスタをソフト屋風情で構築するか
最初に断るが、筆者は根っからのソフト屋である。14歳の時8080なる計算機に 接して以来、ずっとソフトをひたすら書いてきて、今の自分がある。最近は、研 究の一環で、コモディティクラスタをスローガンに、ソフト屋ながら100~数百プ ロセッサ規模のクラスタを研究室に設計・構築している(手前味噌になるが、日本 の大学の一研究室としては最も大規模かもしれない)。従って、これから述べる返 答はソフト屋の偏見に満ちているといえよう。苦労してハードを開発されている 方々、また、あと数サイクルを搾り出そうとベクトルのチューニングに勤しむア プリケーションの方々には、ソフト屋のいい加減な発言と映るかもしれない(無論 筆者も数サイクルを搾り出すのは好きである)。しかしながら、それでもあえて申 し上げれば、少なくとも現状のアーキテクチャとその指数的速度向上を支持する 計算機産業、およびその活用が続く限り、今後は最もハイエンドを含むHPCにおい て、コモディティのハードウェアを活用する以外feasibleな道はない、と断言し たい。それはいわば高額で専用開発される大規模専用ベクトル並列計算機時代の 終焉を意味し、コモディティ技術に基づいた大規模クラスタの時代がいやおうな しにやってくる、ということである。そして、そのとき最も中心とされる技術な のは、もはやハードウェア技術ではなく、ソフトウェア基盤であり、あるいはク ラスタコンピューティングに対応したアルゴリズム、それをベースとした新世代 のアプリケーション群である。HPCはそれら「ソフトウェア」に今後は研究開発の ほとんどの努力を向けるべきである、と強く主張したい。以下に、その理由をソ フトウェア屋の立場、また経済性の立場、などから述べよう。それによって、な ぜソフト屋である筆者が大規模コモディティクラスタを構築するのに腐心するの かが明らかになれば幸いである。
まず、朴氏が述べられていたことに対しては、ほとんどの点については同意見 である。我が国のHPCがASCIに代表される米国の大規模MPPに押されていること、 HPCの経済的パイが小さい現状ではベクトル機の新たな開発が難しいこと、ベクト ル機の方がどちらかというと汎用性が高いこと、などである。しかし、朴氏はそ れらの観測に基づき、従来型のベクトル機と比較してMPP&クラスタのキャッシュ への依存度の高さ、および高メモリスループットに支えられたベクトル技術の成 熟さ、さらにクラスタの部品点数の増加によるMTBFや設置性の問題などから、今 後もベクトル技術をHPCで捨てるべきではなく、クラスタはlow-end HPCのみに有 効だとしている。本当にそうだろうか?
筆者には、まさにそのようなハイエンドベクトル偏重主義は戦艦大和(我々の世 代は宇宙戦艦だったが)を引きずった第二次世界大戦の旧日本海軍的いわば巨砲 (Big Iron)主義に映る。そうではなく、もはや時代は機動性の高い超音速戦闘機 (Fast Commodity CPU)+空母(クラスタ)+哨戒システム(Software)に遷移している と主張する。ただし、これはアナロジーとしては感覚的には正しいが、技術的に は無茶苦茶であるので、以降はクラスタがハイエンドからローエンドまであまね くハイエンド(つまり、超高額)ベクトル機を今後駆逐していく技術的な妥当性を 述べていきたい。
今後のコモディティCPUの動向
まず、最初に断るが、筆者は別にベクトル技術が無用になると言っているので はない。そうではなく、スパコンにしか用いられないようなベクトルプロセッサ を作っても、総合性能でクラスタに凌駕されると述べているのである。むしろ、 ベクトル技術はすでにコモディティプロセッサにDSP的な処理の高速化の切り札と して、すでに多く用いられている；PentiumIIIのSSE/SSE2, AMDの3D-Now!, PowerPC-G4のAltivec, AlphaのVisual Instruction Setなどである。これらはベ クトル長は比較的短い、多くは単精度に制限される(SSE2以外)という制限を持つ が、基本的にはベクトル/SIMD技術の応用であることに変わりない。単精度であれ ば、現状でもPeak性能は1Ghzで4GFlops (PentiumIII, SSE)にもなる (multiply-addの場合)。実行性能でも、Kentucky大学の700MhzのAMD Athlon × 64台のクラスタであるKlat2クラスタ(http://aggregate.org/KLAT2/)では、 3D-Now!でベクトル最適化したBLASで、64GFLOPS以上、つまり単体性能で1GFLOPS を超えている。さらに、2000年冬ごろ出荷されるPentium IIIの後継のIntel Williametteでは、SSE2で倍精度のSIMD計算もサポートしており、(演算ユニット の数によるが)ピーク性能は1.5Ghzで3GFLOPS〜6GFLOPSと推定される。組み込み CPUでも、Sony/東芝のPlaystation 2内蔵のEmotionEngineはやはり同様の技術で 単精度6Gflopsの性能を得る。
さらに、今後1-2年は、1) x86系のスタックベースのFP系の演算命令が、Intel, AMDともに排除され、より高速処理に向いたISAとアーキテクチャに変更される方 向にある。Intelは先のSSE2であり、AMDは次世代のSledgehammer（K8）では通常 のRISC流のExtended FP Instruction Setを採用すると発表している。詳細は不明 であるが、当然多くのFPレジスタ、multiple issue, fused multiply-add、 prefetchなどを兼ね備えていると思われる; AMDによると、最もHigh-endのRISCプ ロセッサに対する実行ペナルティは10%以下だとしている。さらに、2) 競争によ る急激なDie shrinkとそれに伴うクロックの上昇、およびL2 Cacheの増加が挙げ られる。以下は、Hans de Vries氏による今後のAMDとIntelのプロセッサのミクロ ンルールの微細化によるクロックの向上、およびダイ面積の変化である。
Mustang(Athlon Ultra) Willamette/Gallatin (Post Williamette) 180nm 1.3-1.7Ghz 140mm2(256K) 268mm2(1.5MB?) 150nm 1.3-1.7Ghz 1.5-1.9Ghz 96mm2(512K) 97mm2(256K) 120mm2(1MB) 186mm2(1.5MB?) 130nm 1.5-1.9Ghz 72mm2(512KB) 90mm2(1MB), 〜120mm2(2MB)
最新のAthlon(Thunderbird)のダイ面積が約120mm2なので、2001年の0.13プロセ ス時には2Ghz, L2 2MB程度のプロセッサがコモディティの標準となる。ここで、 L2容量の急激な増加に注目されたい。.18から.13への移行によるトランジスタ数 の増加は2倍程度であるが、ロジックのトランジスタ数は同じアーキテクチャなら ばそれほど増加しないので、その分がL2の増加に回せる；AthlonではMustangの増 加は現状のThunderbird(256K)に対して4-8倍にもなる。大容量のL2は数値計算の ピーク性能を維持するのに大変効果を発揮することが多い。
1), 2)を総合すると、コモディティプロセッサの倍精度演算のピーク性能は、 2002年には8GFOPS以上であり、SledgehammerのようにFPユニットが増える、ある いはベクトル演算が強化されれば10GFLOPSを軽く超えると予測される。よって、 2002年の時点で100node程度(数千万円程度)のクラスタでもピーク性能は軽く Teraflopsを超える可能性が高い。このような急速なコモディティCPUの性能向上 にベクトルの開発は追いつくのであろうか? コモディティプロセッサの市場規模 は数兆円であり、開発にはIntel, AMDなど各社莫大な数の人間が携わっていて、 さらに最新のプロセス(SOI, Copper Interconnect)などが惜しみなく用いられ、 毎月のように新しいアーキテクチャやクロックの高速化が発表されているのが現 状である。これに対して、(プロセッサだけ見れば)市場規模が1/1000以下の従来 型のスパコンがタイムリーに太刀打ちできるとは思えない。
It's the Bandwidth, Dammit----コモディティメモリバンド幅の劇的な向上
プロセッサのピーク性能が上昇しても、メモリバンド幅が向上しなければ、限 られたアルゴリズムしか性能向上しない。かのSeymore CrayはHPCアーキテクチャ の肝は "It's the Bandwidth"と言ったことで有名である。しかるに、現状のPCで はメモリバンド幅は500MB/秒程度であり、一方スパコンはバンクメモリを駆使し て数GB/秒以上である。このままではHPCの足かせになる。
しかし、良く知られているように、この1-2年ではコモディティにおいてもメモ リバンド幅の急激な向上がある。一つはCPU性能の向上であるが、もう一つはグラ フィックス性能の向上に大きな需要がある。PlayStation2はDual Channel DRDRAMを用い、メインメモリは3.2Gbyte/秒のバンド幅を持つ。Intelの Williametteも同様であり、Alpha 21364では4チャンネルで6.4GB/秒を誇る。一方、 PC系のグラフィックスカードや、AMD Athlonなどは DDR-SDRAMを用いる。現状で は2.1GB/秒のPC2100が規格化されるが、Dual DRDRAM同様の3.2GB/秒のPC3200も規 格化されようとしている。すでに3Dグラフィックスカードでは400Mhzの DDR-SDRAMを用いた6.4GB/secのカードがこの秋に登場予定である。さらに両陣営 ともコスト削減とバンド幅向上に熾烈な戦いを繰り広げており、Quad-Data Rate のDRAMも規格化が検討されている。
無論、これらは従来のマルチバンクメモリと比較して、ランダムアクセス時の レーテンシが大きいなどの問題点がある；が、連続アクセスを行ったり、超高速 なプロセッサ内の大容量L2キャッシュを使う、あるいはDMA転送を効果的に併用す れば、その莫大なバンド幅を生かせるであろう。すでにPentium IIIでは内部キャッ シュバンド幅は32GByte/秒に達しており、レーテンシも7 clockである。ソフトウェ アにおけるそれらの重要性は後述する。
6GB/秒のメモリバンド幅を持つノードによって構成される100ノード程度のクラ スタの祖総メモリバンド幅は600GB/秒である。これは「1FLOP:1MByte:1Mbyte/秒」 とするかの「Oyanageeの法則」には多少足りないが、かなりスパコンに近いとい えよう。
本当に高速ネットワークは必要なの?
ネットワークにおいても急激なコモディティ化は進行している。バンド幅の向 上が例えばEthernetでは10倍づつなので実感しにくいが、2000年後半にはCopper の1000Base-TXが一般的になり、スィッチも急激に安くなっている。同時に、 10Gbit Ethernetの実験も成功しており、さらに多少高くはなるが、Myrinet, Giganetなどの高速かつスケーラブルなインタコネクトも存在する。肝心のI/Oバ ンド幅も、PCI-X、さらにはInfinibandで急激に向上する。総合的には、近年のネッ トワークのバンド幅の向上はMooreの法則を超えており、プロセッサの速度向上を も上回る。
無論、ハイエンドのネットワークはカードや個々のノードのI/Oは比較的急激に 低価格になるが、スィッチはなかなか下がらないなどの問題もある。しかし、今 や 2年前は下手をすると20-30万円した100Base-Tのスイッチが8990円で売られて いる。コモディティのチップセットが開発されると、premiumを払わなくてはなら ない CPU以外の周辺機器は(同程度のミクロンルールで製造されれば)劇的に価格 が下がる傾向がある；これぞコモディティの恐ろしい性能向上のカギである。
さらには、本当にそれだけのネットワーク性能が必要かという観測もある。こ れは先のバンド幅の議論と多少矛盾するが、基本的にクラスタで並列化される数 値アルゴリズムは本質的に何らかの局所データに対する反復処理を行い、全ての データを通信しないものが多い。このような場合は、プロセッサの速度向上に対 して、ネットワークの性能はそれほどなくても大丈夫である。例えば、単純な数 値アルゴリズムを考えると
問題サイズ 通信 EP O(n) O(1) SOR O(n^2)(ブロック化したタイル辺) O(n) Particle O(n^2) O(n)以下 (local interaction, 各プロセッサの粒子数)
このような場合は、プロセッサの性能向上による速度向上に対して、ネットワー クの性能向上のオーダーは低い。例えば、Blocked SORにおいては、仮にプロセッ サ速度が10倍になった場合、通信速度は3倍程度にしか向上しなくて良い。無論 「現実のアプリケーションはそんなに単純じゃないぞ」「「ランダム通信はどう するんだ」とか「FFTのように細かい通信がいっぱいあったらレーテンシはどうす るんだ」とかいろいろお叱りを受けるのは承知しているが、そのワーストケース を考えてハイエンドネットワークに湯水のようにお金を注ぐのがスパコンの発想 であり、それらをハードウェアではなくソフトウェアやアルゴリズムで解決しよ うというのがクラスタの発想である。しかも実際、筆者らの実験では、現状のプ ロセッサでは、100Base-TでもNASPARのほとんどのベンチマークで、驚くほどの性 能とスケーラビリティを発揮するが、それは上記の理由に追うところが大きいと 筆者は考える。
じゃあ単にPCを並べればよいの?---It's the Software, Dammit!
では、今後ハイエンドPCを単に並べればスパコンにになるか? 答えはまだまだ Noである。朴氏も指摘しているが、現状のクラスタでは高度にチューニングされ たそれ向きのアプリケーションは高性能が得られるものの、ベクトルスパコンほ ど汎用ではない。しかもSingle System Imageを実現するソフトウェアのロバスト 性、コンパイラやランタイムやその他ツール郡を含む言語システムの性能・機能 ・安定性、I/OのSingle View化、MTBFを含む管理の容易性の向上などで、まだま だ長い年月をかけて開発されてきたベクトルスパコンには劣るといえよう。さら に、問題はアルゴリズムやアプリケーションであり、超高速な大容量キャッシュ +ショートベクトル処理+租粒度並列に対応した高性能数値アルゴリズムやアプリ ケーション、ならびにその記述を容易にするソフトウェア技術が必要である。
とどのつまり、今後のHPCは本当の大規模のものからローエンドまで、クラスタを 是とすればあとはソフトウェアの研究開発の問題となる。それゆえソフト屋の活 躍する場が出てくる；上記の問題は本質的にソフトウェア技術に対する大きなチ ャレンジであり、それを解決することによって、本質的に圧倒的にコストパフォー マンスが高く、かつテクノロジーカーブに載って性能が向上するクラスタがスパ コンを一気に凌駕することは目に見えている。米国ではすでにそれが起こってお り(それでもまだハイエンドのRISCに対するこだわりは強く、まだまだコストが高 いが)、わが国は圧倒的に立ち遅れている。無謀なような主張に聞こえるかもしれ ないが、今後のHPCはハードウェアは「クラスタでいいじゃん」として、それ以外 の本質的開発はほとんど全て(アプリやアルゴリズムを含む)ソフトウェアに勢力 を注ぐのが肝要であると述べたい。例えば数値アルゴリズム屋さんも、キャッシ ュマネージメントをうまく行うようなアルゴリズム以外は今後実用的には無価値 になる可能性を悟るべきであるし、アプリケーション屋さんもクラスタをターゲッ トとすることでユーザベースが圧倒的に広がるであろう。ソフトウェアと実用性 という観点からは、クラスタはようやく夜明けが始まった、といった感じである。
誤解していただきたくないのは、決してハードウェアのハイエンドの新しい技術 開発自身が無意味だと言っているのではない。そうではなく、それがコモディティ に降りてくるようなビジョンや作戦がなければ、所詮はコモディティの急激な速 度向上とコストパフォーマンスに負けてしまう、ということである。そこでは素 晴らしいハードウェアだけではなく、それに付随したソフトウェアの開発コスト も、コモディティに載っていないゆえ、回収できない。例えば、日立/筑波大の擬 似ベクトル技術は素晴らしいものである；例えば、TOP500でのRPeakに対する性能 を見ても、従来のベクトル計算機並みの効率を出しており、MPPやクラスタ計算機 が50-60%程度の効率にとどまっているのとは対照的である(上記の理由により、今 後はクラスタでも効率は向上する可能性はある)。が、現状では(日立のSHなどを 含めて)コモディティプロセッサはそれを採用する動きは(少なくとも筆者の知る 限りは)無く、結局は従来型のベクトル計算機と同じコスト構造になってしまって いる。一方、EEを含むコモディティプロセッサはSIMD型のベクトル技術を採用し、 成功を収めているが、擬似ベクトルを使えない積極的な理由は見当たらない。今 後のFPが増加する可能性の高いコモディティプロセッサにとって、せめて Preload (キャッシュをバイパスするload)でもあれば、高速なL1へのspillと併用 して擬似ベクトルに近い恩恵に預かれるのであるが。しかるに、Intelと日立は双 方ともそれぞれのベクトル技術に対して自動ベクトル化コンパイラを開発してい るが、IntelのコンパイラはVTuneのパッケージに含まれており、数十万〜百万人 のデベロパと数億人のユーザが恩恵に預かれるのに対して、同じ程度の手間とお 金をかけたであろう日立のコンパイラは、わずか数十〜数百台のSR2201/SR8000の インストレーションにしか益をもたらしていないのである。擬似ベクトルをコモ ディティ化するという計画があれば、それは大変好ましい選択であると考える。
おわりに: 地球シミュレータに勝てるの?
最後に、地球シミュレータに「勝つ」クラスタを考えると、2003年に仮に.10ミク ロンに移行出来たとすると、その時点ではクロックは2.5Ghz以上、また64bitアー キテクチャが主流になり、コモディテイでもより強力なFPやベクトル処理とあい まって、単体性能は10-20GFLOPSを超えると考えられる。20GFLOPSとすると、ピー ク性能比較では2000台で地球シミュレータに匹敵する。無論実行性能は別問題だ が、現状のASCI Redの1/5のサイズで良いのである。それがコモディテイの進歩の 恐ろしさでもあり、それゆえそのソフトウェアが重要になる。しかるに、ソフト 屋の筆者がクラスタを構築する所以である。
もっとも、これからはJJとか、量子コンピュータとかの天変地異が起こるかも しれない。その時はその時でソフト屋は失業しないのである。。。
(2000.6.20)
これでいいのか？ 日本のスパコンＸＸ
関口智嗣 ／ 通商産業省 工業技術院 先端情報計算センター
「これでいいのか？ 日本のスパコン」において、朴先生はクラスタごとき積み木 細工の安易な（知恵のない！）成金趣味的性能至上主義を謙虚に批判し、スパコ ンアーキテクチャの行く末を憂いた。スパコンのあるべき姿は「自然界をそのま ま模倣するし、神の意志を忠実に再現する神器であれ」という教え（出典：PAX Parallel 教団聖典）を盲目的に信奉すると、やはり「クラスタごとき」庶民的な システムは受け容れ難いものだろう。本来の教義の解釈は若干異なるのだが、そ れは長くなるのでここでは触れない。スパコンとは時代の先端を行く高尚なアー キテクチャ、門外不出の詳細なハードウエア仕様、霧とベールに包まれたマシン 室、決して手に入れることのできない定価表、伝説の最適化パラメータ、呪術の ようなディレクティブとコンパイラオプション、人生を掛けたプログラミング、 などの教えを次々と伝授されることによって、経験値を積み、初めて拝ませてい ただける資格が得られるという、とてもありがたい存在である。したがって、 「クラスタごとき」庶民のアーキテクチャ、全部動作が見えちゃう恥じらいのな いＯＳ、神秘性のないおっぴらけのＯＳだと所詮、たかが知れてるってことです よ。「神の国」日本においては崇高な科学技術計算の象徴的意味合いにおいて、 これからも伝統工芸品としてスパコンを製造し続けなければならないというのが、 隠された真意であったのだろう。
これでいいのか？ 日本のスパコンユーザ
第１世代のスパコンユーザ（CRAY-1）や第２世代(CRAY-X/MP, S810, VP200, SX-2) からの筋金入りのユーザは、今でも実力・経歴とも尊敬に値するもので、 数々のシステムにおける逸話の語り部であったりする。一言一句に時代と歴史を 感じさせる重みがある。
しかし、今のユーザはどうだ。９０年代の補正予算で次 々と導入されたスパコンが、ふるさと創生ではないが全国津々浦々に配備され、 誰でもが気軽に触れるようになってしまった。修行なんて必要なし。手元のワー クステーションよりちょっと速いからというだけの理由でスパコンを乗り回され たんじゃ困ります。スパコンは遠くにありて思うもの。決して、CPU時間じゃぶじ ゃぶな環境にユーザを漬け込んじゃいけません。彼らは、スパコンに「触れた」 ことを「神の領域に達した」と勘違いし、選民意識だけを引き継いでしまった。 その実、やっていることはスパコンのファミコン化、すなわち購入してきたソフ トウエアをカパチョンとセットして、時間のある限りそれと戯れている。ちょっ とずつ違うインプットデータを入れては、答えを待つ。確かに、スパコンを使っ ているが、そこには神器に触れているという感慨も厳粛さも、ましてや神秘性な ど感じる術もない。このようなユーザにはクラスタでも喰らわしておけば十分で ある。
ん、まてよ、クラスタやASCIなシステムはとある国の得意とする分野。そし て、ここでのファミコンソフトは、本当のファミコンソフトが日本製なのと違っ て、ほとんど輸入に頼っているもの。これは、日本における産業基盤ソフトウエ ア、半導体・代替エネルギー・環境・新材料・薬物等の産業における設計・製造 ・実験などに計算科学的手法を取り入れたソフトウエア、も輸入超過にして、技 術の空洞化を誘発し、同時に日本が得意としていたスパコンアーキテクチャを壊 滅的に葬り去る戦略かも知れない。
先進的ユーザ諸君、日本の産業技術の空洞化 を救うのは君たちだ。早く目を覚ましてくれ。スパコンとパソコンを比較して、 性能の良否を議論しないでくれ。マシンの、コンパイラの、ネットワークの、ファ イルの、ライブラリの（あぁ、列挙していて虚しい）挙動が怪しいからといって、 スパコンベンダーに対して勝ち誇ったような言い方をしないでくれ。歩みは遅く とも、彼らは神の使いとして全知全霊を傾けているんだ。せっかく、潤沢な計算 資源をもらったのだから、もったいないお化けが出るなど言わずに、全部を使い 切ってみてくれ。情報の人たちを「なんで、最適化なんかで論文が書けるの？ ど こがサイエンスなの？」などと見下さず、耳を傾けてみてくれ。本当の敵はそこ にはいない。
これでいいのか？ 日本のスパコンセンター
日本のスパコンセンターって、実は難しい。確かにスパコン（今の定義によれば １００GFLOPS以上）を保有する計算センターは国立のものだけでも旧七帝大に設 置された共同利用施設をはじめとして、科学技術庁研究所関連、通商産業省工業 技術院関連など２０を越える。TOP500によれば 高エネ研、東大、物性研、名大、 京大、工技院先端情報計算センター、筑波大計物センター、理研、分子研、気象 研、東北大、金材研、航技研、北大、統数研、地球フロンティア、東工大、核研、 阪大、九大、原研、などである。これらの計算センターのうちほとんどは（当然 であるが）特定ユーザのためのサービスであり、それぞれの企画・運営は良い意 味で孤高を誇っている。
しかし、米国のスパコンセンターのリストラを見よ。米 国ではNPACI(National Partnership for Advanced Computational Infrastructure) という全米仮想計算基盤センターとしてサンディエゴスーパーコンピュータセン ター(SDSC)を中心に再構成を行った。実際の計算機は全米に分散配置されている が、これらを統一的に見せる仕掛けを作って、ユーザからはあたかも単一システ ムのように見えている。大学や国立研究所等で開発された萌芽的ソフトウエアや ツールの中で実戦配備に役に立ちそうなものをThrust Areaとして数千万円規模の 開発費を渡し、成果物をNPACIに導入するという手法を用いている。これによりNPACI が主導的に「世の中にすぐに役立つ技術」を選定している。 これにより、メタコ ンピューティング、グリッドといったセンター間やサイト間に跨った計算機利用 技術も非常に現実的なものとして議論がされている。
翻って日本ではどうか。た とえば、つくば地域で高速ネットワークを引いて、お互いのスパコンをちょこっ とずつ時間貸し借りするような実証的実験をしませんか？とある会議で提案した ときの反応は （１）他のサイトに貸すCPU時間があることが会計検査院にばれると 困る［でも、ファミコンのようなCPUの使い方をして資源を浪費するくらいなら］、 （２）セキュリティ、そうセキュリティが大変なんだよ［もちろん、そのとおり ですが、それが研究課題なんだけどな］ （３）あちこちのスパコン使ってもね ぇ、ユーザは面倒だと言っているよ［だから、ミドルウェアの研究と配備を積極 的に実証することが必要なんですよ！！］ とまぁネガティブな反応ばかりであ った。
しかし、これでは積極的に新しいネットワーク・ＩＴ技術の導入を図って いる諸外国との格差は拡がるばかり。少なくとも先端情報計算センターは独立法 人化に向けてのビジネスを展開しないと運営費が未来永劫保証されるものじゃな い。通商産業省的に言えば今までの限られたユーザばかりでなく、新規産業創出 を企てる中小企業にもスパコン利用機会の提供を与えることで産業基盤の強化を はかり、スパコン利用の実需を掘り起こす必要があるのではないか。これで、高 々数百億円といわれるスパコン市場を拡大していくことができるのではないか。 スパコン技術の独立採算では赤字だそうだか、こうした市場拡大の努力をスパコ ンセンターも協力するべきではないだろうか。このことが、スパコンベンダの体 力強化となり、センターにも世界に誇れる素晴らしいモンスターが導入されるこ とになるだろう。
これでいいのか？ 日本のスパコンプロジェクト
ここ数年、未曾有のHPC(High Performance Computing)技術への追い風が国内外で 吹いている。陽の目の当たらなかった当時の「数値解析研究会」を「ハイパフォー マンスコンピューティング研究会」への衣替えに関わった一人として、感慨に耽 るものがある。とはいえ、未だ客観的に過去を振り返って語れるような時代では ないし、まだ小生も現役としてまだまだこの分野への貢献をしていきたいと考え ている。
例えばスパコン大プロなどかつては独自のハードウエアを中心とし、そ の回りのソフトウエア群を開発し、応用問題を載っけてお終いというシステム開 発型のプロジェクトスタイルが典型的であった。しかし、（１）ハードウエアや アーキテクチャの詳細は非公開、（２）世の中のトレンドを見ないソフトウエア は特殊仕様で融通が利かない、（３）人材がどこで育っているのかわからない、 ということで、プロジェクト終了後、じわぁーっと来るものが少ないのが常であ った。今ではとてもはやらないスタイルである。
その点、米国の（とばかり言うのは気が引けるが）をモデルとしつつ、（１） 公開型のプラットフォームで「ミニ版」は研究参画者でも手が届く範囲で利用 可能、（２）独断でなく世の中のト レンドを意識したソフトウエアの開発技術と汎用化、（３）特定のサイトに閉じ ず大学、研究所における人材育成、（４）マイクロプロジェクトを多数作らない ようにプロジェクトのコーディネーション（５）応用分野とのEqual Partnership と技術の橋渡し、（６）国内外への積極的な情報公開、（７）公平なプロジェク ト評価システム、が期待されるのではないか。この追い風に乗っていくつかのプ ロジェクトが立ち上がってくるかも知れないが、「HPCって、スパコンって、なぁー んだ」と指さされないように、産学官で力を合わせて頑張っていきましょう。我 々の未来のために。
(2000.6.20)
It's still the Bandwidth!
朴 泰祐 ／ 筑波大学 電子・情報工学系/計算物理学研究センター
スパコン話に予想以上の反応があり嬉しい悲鳴をあげている。渡辺氏・松岡氏・ 関口氏の各視点からの意見を面白く読ませて頂いた。
結局「スパコンはやっぱりバンド幅」という結論は変わらないようだ。渡辺氏 の意見はもちろんのこと、松岡氏の意見も裏を返せばクラスタが適用できるの はメモリバンド幅を食わない、あるいはそれを隠せるアプリ、ということにな る(「コモディティのバンド幅は増えてるぞ」と主張しているが、まだまだ不 足)。スパコンに金がかかっているのはまさにこの点であり、SSEやらEmotion EngineのSIMD命令があっても「釈迦の掌」でしか動けない。掌を大きくするか、 少なくとも大きく見せる工夫が必要だ(本誌1999年9月号のインタラクティブ・ エッセイの中村氏の意見にも関係する)。結局は適材適所ということになって しまうかもしれないが、まだまだ当分はスパコンとクラスタの棲み分けは続き そうだ。また、スパコン技術のバックアップのためには単にメーカを後押しし てマシンを作らせるだけでは駄目、という関口氏の意見もよくわかる。単純な 「護送船団方式」ではない将来を見据えたプロジェクトは重要だろう。
日本が何らかの形でスパコン技術的に世界をリードして欲しいという思いは皆さ ん共通のようだ。限られた紙面ではこの程度のまとめしか書けないが、このテー マはまだまだWWW上で続いてほしいと思う。頑張れ、日本のスパコン！
(2000.6.22)