スパコン素人談義とTOP500   

2004年11月30日



☆11月の水田に広がる「ひこばえ」の緑野   
TOP500更新で地球シミュレータがついに首位から陥落した。 ドッグイヤーと言われるこの世界では首位陥落は単に時間の問題であり、 いかなるコンピュータでもいずれはそうなる宿命を背負っている。 問題はいつまで首位を維持できたかであり、 その点では地球シミュレータは首位5期2年半という 特筆に値する成果を出してきた。 LINPACKという名目値での首位はプロの予想でさえ4期2年だったから、 それすら越えた大健闘とさえ言える。

ここでいつも考えるのは、アメリカ同様にスカラパラレル方式を採用して 商用プロセッサでマシンを組んでいたらどうなっていたかだ。 まず、実効効率が低下するから理論ピーク性能で少々上回っても実効性能が 逆に低下するのは必定である。また、地球温暖化の研究という本来の目的での 性能は流体コード故にキャッシュが効かずさらに大きく性能低下し、 こちらの方が本業故にさらに深刻な致命傷になっていたはずだ。

多分LINPACKでの首位の座はもっと短かっただろうし、 大気大循環プログラムで26.58TFLOPSを出すことなどまず絶対に不可能で、 ゴードンベル賞も逃していたのでは無かろうか?

考えても見て欲しい。 2年半前に世界の頂点に立ったコンピュータが、つい1ヶ月前まで世界最速 だった。 これをPCの世界に当てはめてみよう。 2年半前の最速CPUはPentium4の2.53GHzだが、これがつい1ヶ月前まで 世界最速であり続けた、なんて事態が考えられるであろうか?  PCの世界ではまったくあり得ない話である。

だが、それでも一抹の寂しさは残る。 ベクトルパラレル方式というスパコンでは特異な方式を採用し、特に実アプリ性能で 各方面から絶賛された機種だけに、正直まだまだ頑張ってもらいたかった。

ただ、ランキングは別としてその使用目的は今でも重要である。 地球シミュレータは地球温暖化の原因と影響の解明という重責を担っているからだ。

実際、地球温暖化は人ごとではない。あと1日で12月と言うのに、 冬らしく寒くなったのはようやく昨日からである。最近の異常な温暖化は 皆様も実際に体感していらっしゃる事と思う。 ちなみに、この冬は当サイトの部屋ではまだ暖房を使ったことが一度も無い。

会社の行き帰りに見かける光景はもっと奇妙だ。 下記の写真を見ていただきたい。

「ひこばえ」の緑野が広がる水田
明日はもう12月だというのに...地球温暖化もここまできた。

この写真は刈り入れ間近な9月の水田...と言うわけではない。 実はこの週末にご近所の水田で撮影したものである。

このような稲の切り株から新しい稲が成長することを「ひこばえ」というが、 普通は途中で寒さのため枯れてしまって、稲穂を実らせる事はない。 しかし、今年はこの温暖化のため、稲は枯れることなくすくすくと成長し、 まるで夏の光景のような緑の水田を生み出してしまった。 (よく見ると、稲穂もちゃんと実っている。)

12月といえば普通は灰色の切り株が水田の光景なのだが、 ここは千葉の北総地方だというのに、これではまるで高知の二期作である。 (というか、本場高知でも最近は二期作は珍しいらしい。)

それだけではない。 こんな異常気象が毎年のように「観測史上初」を連発している。 たとえば、今年の「観測史上初」は温暖化による台風の異常発生だ。 例年の3倍近い数の台風が列島を直撃した。

台風が直撃すれば、スパコンの建造費など一瞬で吹っ飛ぶ程の経済被害が生じる。 つまり、研究成果次第で高い建造費を払っても十分ペイするわけで、 その評価は成果次第で大きく上下するであろう。 (もっとも、地球シミュレータは台風の進路予想といった短期スケールでの シミュレーションを想定してはおらず、もっと長期の予想を担うわけだが...)

そして、これが地球温暖化ともなれば被害は台風どころではなく 全地球的規模になるわけで、 TOP500だけで地球シミュレータの評価を下すのは早計だ。 その評価は本業の研究成果次第ということになるだろう。

☆TOP500概観   
ということを頭に入れて、TOP500の結果を見てみた。

まずここで、今回のTOP500を見る前に歴代TOPを一覧表で見てみよう。 これを見ると、非常におもしろいことがわかる。

まず、わかるのは歴代首位のマシンが日本とアメリカの2カ国だけで 建造されていることだ。 今、中国勢等のスパコン上位進出が注目されているが、日米と異なり、 かれらは自前のCPUを作っているわけではない。 中国人の方々には失礼な言い方になって大変に恐縮なのだが、本当の意味で スーパーコンピュータを作る実力があると言えるのは日米だけである事が この歴代首位一覧からわかる。

ちなみに首位回数であるが、事実上日米の一騎打ちである。 このため、これを対抗戦として考えると日本の11勝13敗である。 スパコンの能力を国力に比例すると考え、国力をGDPで代表させるとすると、 GDP比は約1:2だから8勝16敗で対等と考えるのが賢明である。 経済誌などでよく見られるが、日本は何でもダメダメ評価の 「日本ダメダメ論者」に見せてやりたい健闘ぶりではないか? 

最近の日本勢は地球シミュレータを除けば長期的凋落傾向にあるが、 このように歴史的に見れば日本はかなりの栄光を背負って立っている。

日本は腑抜けるにはまだまだ早すぎる、 挽回のチャンスは十分あると言えるだろう。 優秀な技術陣は健在であり、足りないのは技術ではなく 政府のやる気である。

次におもしろいのは、首位争奪戦が日本のベクトル機対アメリカのスカラ機に なっているのが、単なるプロパガンダではなくデータ上の事実である点だ。

初代首位のCM-5がアメリカ製ベクトル機である点を除けば、 アメリカ製はすべてスカラ方式、日本製はすべてが ベクトル方式または疑似ベクトル方式である。

この戦いの行方は後日掲載するが、スカラ方式である BlueGene/Lがトップに立ったことで一見するとスカラ勝利のように見える。 だが、実はIBMがベクトル方式の優秀性を認める形で 疑似ベクトル方式に転向した事は特筆すべき事だろう。 次代のIBM製スパコンは疑似ベクトル方式になる可能性がきわめて強い。 こと科学技術計算に限れば、決着は付きつつあると言えるだろう。

年代 1993/6 1993/11 1994/6 1994/11 1995/6 1995/11 1996/6 1996/11 1997/6 1997/11 1998/6 1998/11
スパコン機種名 CM-5 NWT XP/S140 NWT NWT NWT SR2201 CP-PACS ASCI Red ASCI Red ASCI Red ASCI Red
理論ピーク性能 0.131 TFLOPS 0.236 TFLOPS 0.184 TFLOPS 0.236 TFLOPS 0.236 TFLOPS 0.236 TFLOPS 0.307 TFLOPS 0.6142 TFLOPS 1.453 TFLOPS 1.8304 TFLOPS 1.8304 TFLOPS 1.8304 TFLOPS
LINPACK実効性能 0.0597 TFLOPS 0.1245 TFLOPS 0.1434 TFLOPS 0.1704 TFLOPS 0.1704 TFLOPS 0.1704 TFLOPS 0.2204 TFLOPS 0.3682 TFLOPS 1.068 TFLOPS 1.338 TFLOPS 1.338 TFLOPS 1.338 TFLOPS
製造国 アメリカ 日本 アメリカ 日本 日本 日本 日本 日本 アメリカ アメリカ アメリカ アメリカ
方式 ベクトル ベクトル スカラ ベクトル ベクトル ベクトル 疑似ベクトル 疑似ベクトル スカラ スカラ スカラ スカラ

年代 1999/6 1999/11 2000/6 2000/11 2001/6 2001/11 2002/6 2002/11 2003/6 2003/11 2004/6 2004/11
スパコン機種名 ASCI Red ASCI Red ASCI Red ASCI White ASCI White ASCI White Earth-Simulator Earth-Simulator Earth-Simulator Earth-Simulator Earth-Simulator BlueGene/L beta-System
理論ピーク性能 3.154 TFLOPS 3.207 TFLOPS 3.207 TFLOPS 12.288 TFLOPS 12.288 TFLOPS 12.288 TFLOPS 40.96 TFLOPS 40.96 TFLOPS 40.96 TFLOPS 40.96 TFLOPS 40.96 TFLOPS 91.75 TFLOPS
LINPACK実効性能 2.1213 TFLOPS 2.379 TFLOPS 2.379 TFLOPS 4.938 TFLOPS 7.226 TFLOPS 7.226 TFLOPS 35.86 TFLOPS 35.86 TFLOPS 35.86 TFLOPS 35.86 TFLOPS 35.86 TFLOPS 70.72 TFLOPS
製造国 アメリカ アメリカ アメリカ アメリカ アメリカ アメリカ 日本 日本 日本 日本 日本 アメリカ
方式 スカラ スカラ スカラ スカラ スカラ スカラ ベクトル ベクトル ベクトル ベクトル ベクトル スカラ

あとは、地球シミュレータの5連覇が如何に長期の覇権だったかも この表から伺える。

長期覇権ではASCI Redの通算7期が最も長いが、実はASCI Redは途中3度の 大改修を受けて都度能力を向上させている。 つまり、単一アーキテクチャでの覇権は事実上地球シミュレータが一番長いのだ。

というところで、早速今回のTOP500の結果に移ろう。

TOPに立ったのはBlue Gene/Lである。 その能力は70.72TFLOPS。地球シミュレータの約2倍だ。 世間の事前予想では順当に、 そして当サイトの事前予想では青天の霹靂である。

このスパコンがなぜ最速になったのか当サイトなりに考えてみたのだが、 未だによくわからないというのが実情だ。 当サイトの考えでは、この方式ではどう考えても効率が 上がる筈がない様に思える。

世間の事前予想では理論ピーク性能が180TFLOPS (I/O用プロセッサも計算に転用すれば360TFLOPS) にも達する事が首位候補筆頭の理由とされてきた。だが、 理論ピーク性能は実効性能予想の参考にはならない事は、 RISCアーキテクチャの開祖パターソン先生も その著書の中で認めている紛れもない事実である。

ただし、理論ピーク性能ではなく、効率をそれなりに上げてきたのが トップになった原因である事は間違いないだろう。 その意味では以前からの当サイトの主張に沿った部分も一部ある。 (当サイトでは効率低下を承知でゴリゴリと理論ピーク性能を上げる 物量作戦的設計思想を否定し続けてきた。) なぜならば、Blue Gene/Lにはプロセッサ数のもっと少ないプロトタイプが存在し、 その効率はbeta-Systemより低かったからだ。

スパコン機種名 Blue Gene/L beta-System 地球シミュレータ Blue Gene/L DD1 Prototype Blue Gene/L DD2 Prototype
TOP500順位 1位 3位 8位 15位
理論ピーク性能 91.75 TFLOPS 40.96 TFLOPS 16.384 TFLOPS 11.469 TFLOPS
LINPACK実効性能 70.72 TFLOPS 35.86 TFLOPS 11.68 TFLOPS 8.655 TFLOPS
実効効率 77% 88% 71% 75%
プロセッサ数 32768個 5120個 8192個 4096個

Blue Gene/L DD2 Prototypeの性能を見て欲しい。 今回首位に立ったBlue Gene/L beta-Systemと比べると プロセッサ数が8倍で理論ピーク性能も8倍。 つまり、スケールが違うだけで両者は同じ設計である。 にも関わらず、効率はBlue Gene/L beta-Systemの方が高い。 (Blue Gene/L DD1 Prototypeはクロック周波数が違う。)

これは、プロセッサ以外に何らかの改良が加えられない限り通常は あり得ない事であるとされている。 プロセッサ数が増えれば増えるほど効率は低下するというのが、 スパコン界の常識だからだ。

しかし、実際はプロセッサ数が増えたにもかかわらず効率は上がっているわけで、 計算アルゴリズム面での抜本的改良があったのではなかろうか? と推測している。 (何らかの効率改善用ハードウエア追加の可能性もゼロではないが...)

ともかく、3万個以上という膨大なプロセッサを装備して 77%という効率を出しているのはかなり立派である。 効率の絶対値を見ると地球シミュレータより劣るが、 プロセッサ数のハンデを考えればかなりの健闘と言えるだろう。

☆予想できたColumbiaの高性能と、予想できなかったBlue Gene/Lの高性能   
次に第二位のColumbiaを見てみよう。

スパコン機種名 Blue Gene/L beta-System Columbia 地球シミュレータ
TOP500順位 1位 2位 3位
理論ピーク性能 91.75 TFLOPS 60.96 TFLOPS 40.96 TFLOPS
LINPACK実効性能 70.72 TFLOPS 51.87 TFLOPS 35.86 TFLOPS
実効効率 77% 85% 88%
プロセッサ数 32768個 10160個 5120個

これは当サイトでも高性能なのは予想がついた方式だ。 まず、CPU性能がスカラとしては現状の最高に最も近い Itanium2を採用しているのが良い。 プロセッサ数をなるべく抑えるために、 CPUの個体性能は限界まで高めておくのが良いと考えるからだ。

スカラ方式のCPUから選ぶとしたらPowerPC970かItanium2がベスト というのが当サイトの意見だ。理由は浮動小数点演算性能が高いことと、 Load/Store性能が高いこと。PC用では強い様に見える Xeon等のPentium4系CPUだが、科学技術系算用として見た場合は 積和演算ができるユニットが1個だけで、 なおかつ2サイクル毎に1実行というハンデがある。 なので、クロックが高くても科学技術系算用としては不利と考える。 PowerPC970とItanium2は複数の浮動小数点ユニットを持ち、 どちらも1サイクル1ユニット毎に1実行できる。

さらに、CPU性能が高ければ、プロセッサ数を抑える事で インターコネクトの数的費用負担を抑え、 これにより同じ予算ならばインターコネクトの質的費用を高める事ができる。 実際、Columbiaはファットツリー方式で トポロジ的には単段クロスバ方式に比べると劣るが InfiniBandを使用して短いレイテンシと比較的高いバンド幅を得ている。

対するBlue Gene/Lは3Dトーラス方式だが、この方式は直接網であり、 結合網としての柔軟性に欠けると思う。 隣接ノード間のデータ転送だけですむようなローカリティーの高い 計算では有利だが、データ内容を頻繁に遠方のノード間でやり取るする ような用途だと途中のノードが転送だけの仕事にかかりっきりになって、 ボトルネックになってしまうハズだ。

逆に言えば、隣接ノード間転送だけで片が付くようなアルゴリズムを開発する事が、 このタイプのスパコンで高性能を出す肝であると考える。 スカラパラレル方式での超高並列動作というのは、 真に難しいのはアルゴリズム面での研究開発であろう。 これが、LINPACKでの効率低下が比較的低かった理由を、 アルゴリズム面の改良と想像する所以である。

さて、当サイトが低速CPUの物量作戦がダメだと考える理由は、 インターコネクトに過大な負荷をかける点と並列化効率が急速に悪化する点 にある。逆に言えば、この点を解消できれば物量作戦にも勝機はあるわけだ。

Blue Gene/L beta-Systemでは、プロセッサ数が増えたにもかかわらず 効率はアップしているわけで、その間に何らかの改良が行われたのは必定だ。

スカラパラレルの物量作戦は基本的にはダメ作戦である(と当サイトは考える)が、 1点可能性を考えるとしたら、それは問題のデータ量を減らせば、 物量に訴えることで1ノード辺りの データ負荷が減って、これによりキャッシュのヒット率が上がるという点が 指摘できるだろう。うまいアルゴリズムを開発できればという前提付きだが、 キャッシュ・ローカリティーに頼るコモディティープロセッサの 弱点が一つ解消できることになる。

しかし、実際のアプリでボトルネックになっているのはインターコネクトらしい。 物量作戦ではこの部分のデメリットが拡大するため、 キャッシュ効率の改善分も吹っ飛んでしまうのが通例だ。 実のところ、地球シミュレータが効率面で性能が高いのは、単段クロスバという 世界に例を見ない高性能インターコネクトの性能によるところが大きい。(これは、 開発関係者の方から事実であることを確認している。)

ところが、LINPACKではインターコネクトが低性能でも うまくマスクする方法があるらしい。 つまり、LINPACKに限れば物量作戦がそれほど大きな障害にならないように 工夫する余地があったという点を当サイトが見落としていたのかも?と思う。

ただし、これは後講釈である上に、実際のアプリでは問題になる。 いくらインターコネクトの影響をマスクできると言っても、3Dトーラスのような トポロジで多数のプロセッサをつなぎ止めれば、 レイテンシは1ホップ100nsだから短くできるかもしれないが、 実効的なバンド幅を稼ぐことが難しいはずで、 間違いなく大規模データ転送でボロが出るだろう。

これを解消するためには、3Dトーラスをシストリックアレイのような対称性の高い 高効率なデータ転送に模して、LINPACKでのアルゴリズム変更といった 大がかりな工夫が必要だろう。

また、実際のアプリでは 10倍高速なコンピュータが完成すれば、 10倍難しいシミュレーションをやらせるのが常だ。 実際問題としては、キャッシュ負荷がプロセッサ数の増大により減っていく などということはまず起こりえないであろうことは付記しておく。

☆It's the Bandwidth と It's the Locality   
繰り返すが、3Dトーラスは隣接ノード間のデータ転送だけで片が付く場合は 高性能だが、全ノード間でデータを端から端まで絨毯爆撃するような データアクセスには不向きなハズだ。 キャッシュがローカリティーを活用するアーキテクチャならば、 3Dトーラスもまたノード間データ転送にローカリティーが必要であると考える。

この点では、データをぐるっと全部まとめてアクセスするような用途では ベクトル方式が有利だ。ベクトル方式の最大の本質はベクトル演算ユニットの性能 というよりはむしろメモリシステムのデータ供給能力の高さにある。 天才技術者セイモア・クレイは、スパコンの本質を It's the Bandwidthと表現した。

また、単段クロスバもそのようなアクセスに向いている。 単段クロスバ方式では隣接ノードと遠隔ノードとで、 レイテンシやバンド幅に違いが出ない。 (方式の利点を統一的にまとめている点で、上手に設計されていると思う。)

地球シミュレータは汎用スパコンであるが、 その性質上、基本的に流体コードが高速に実行できる事が絶対必要条件である。 なぜならば、先に述べたとおり地球シミュレータの建造目的のうち最重要なのは 地球温暖化の原因と影響の解明だからである。 この場合、上記のローカリティーに頼らない設計がはっきりと生きる展開 になる。

実のところ、Blue Gene/Lが3Dトーラスを採用したのは、 これが高性能だからではなく、このようなトポロジでないと 多数のプロセッサを物理的につなぎ止めることが不可能になるという、 ある意味物理的な制約からでは無かろうかと考えてきた。

以前、地球シミュレータが単段クロスバという高性能結合網を採用できた理由を 時流に流されなかった開発・地球シミュレータ (ネット・トポロジ編)で素人なりに考えてみたが、 その後、地球シミュレータ開発関係者にお会いして「おおむね正しい理解。」との 評価を得ている。ここでの説明をお読みいただくとわかるが、 プロセッサ数が増えると単段クロスバ網を採用したくても 交換スイッチの数がO(n)に依存するため、 数量的爆発が発生して事実上実装不可能である。 地球シミュレータでの配線量は床が見えなくなる位の力技であり、ノード数を抑えた 設計思想を採用している地球シミュレータでさえこれほどの苦労をしているのだ。

ところが、間接網である3Dトーラスではインターコネクトのハードウエア量が O(n)で済むため、プロセッサ数を膨大な数だけ実装する物量作戦では 実装上非常に有利なトポロジである。

また、プロセッサを格子状に配置することで、伝送ラインの 配線問題も解決できる。 地球シミュレータのような低ノード数の構成でさえ床が見えなくなる位の 配線量なのだから、数万プロセッサの構成でもし単段クロスバをやったら 配線物量面でシステムが破綻してしまう。 地球シミュレータで見せた力技的解決方法を採用できない以上、 最隣接ノードだけを結合対象にする必要があり、 その点で3Dトーラスは最も自然なトポロジである。

3Dトーラスを単段クロスバと比較すると、 性能面では不利だがハードウエア量と実装上の利便性の面では有利 というわけだ。

つまり、プロセッサ数が多いため、効率低下を承知で物量作戦に適した トポロジを採用するしかなかった、 というのが当サイトの結論である。 (この判断は今でも大きく間違ってはいないと考えている。)

ただ、幸いなことにBlue Gene/LはGene(遺伝子)の名前の通り遺伝子解析や タンパク質の折り畳み構造の解析(MDシミュレーション)を主目的にしている。 これらは、流体コードほどノード間データ転送量が多くなく、 また流体コードに比べると比較的キャッシュが効きやすい用途である。 「このような設計思想では、流体コード等はかなり遅いのではないか?」 と言われたら、「そのような用途は主用途ではない。」と正当に反論できる。

それにしても、これだけのハンデを背負った上で77%という比較的高い効率を 出しているのはある意味驚異的で、かなり立派な事であろう。 当サイトは、この点では賞賛を惜しまない。

詰まるところ、Blue Gene/L beta-Systemがトップに立てた理由であるが、 (ちょっと情けないけど...) 当サイトの貧弱な頭脳ではよくわからないというのが真相だ。 やはり、何らかのアルゴリズム面での改良があった と考えるのがもっとも可能性が高いと思う。(だが、今のところ確証はない。)

というわけで、残念ながら、たるさんのアマチュアとしての スパコン修行はまだまだ修行不足ですな、 と認めざるを得ないのがチト悲しい今日この頃である。

ただ、LINPACKという科学技術計算にしてはキャッシュが比較的有効な用途で、 ノード間データ転送も問題になりにくいという特徴がこの性能を支えている 事は間違いないと読んでいる。 Blue Gene/L高速化の肝はキャッシュ・ローカリティーと インターコネクト・ローカリティーにあると言うのが当サイトの結論だ。 もしセイモア・クレイが生きていたらBlue Gene/Lの本質を It's the Localityと表現する様な気がする。

もし、キャッシュレベルでのローカリティーも インターコネクトレベルでのローカリティーも無い 絨毯爆撃的データアクセスを伴うアプリがあったとしよう。 これでBlue Gene/Lが高性能を出せるというベンチマーク結果 が得られた場合は当サイトのつたない推定は瓦解する。 今後各種のベンチマーク結果が発表されれば、その結果は随時報告したい。

Blue Gene/Lが本当に実アプリで高性能かどうかはLINPACK以外のデータが無いので 未だ不明だ。IBMの技術者にはよく使われる実アプリでの性能を公開していただいて、 この疑念を払拭していただくのが吉と思われるのだが、どうだろうか?

さて、今回は肝心の部分の謎が未だ解明できていないという とても情けない内容になってしまった。なので、 次回は気合いを入れる予定である。 地球シミュレータが実アプリではまだまだ世界一である事を プロ中のプロの評価論文をベースに証拠付きで報告してみたい。

参考:TOP500



-お詫びと訂正-
またやってしまったらしいです。 LINPACKの次元数を固定と書きましたが、 可変が正しいとのご指摘を頂きましたので、 この点をお詫びして訂正させていただきます。 本文は訂正済みです。

ご指摘ありがとうございました。