オークリッジが 2008年に 1 Pflops のシステム構築を正式にアナウンスした
り、 IBM が 2010 年までに 10Pflops の BG/Q 開発を表明したりと 2006 年
6 月にはアメリカで大きな動きがありました。 Top 500 の発表もありました
が、首位はもちろん BG/L のままで、東工大の TSUBAME システムが
ClearSpeed なしの数字を出した、というくらいしか目新しいニュースはあり
ません。
東工大が ClearSpeed の数字を出せなかったことについて、詳しい情報がある
わけではないので憶測で書くと、あのシステム構成で Linpack で性能を出す
のに ClearSpeed を使う、というのは不可能ではないかもしれないですが非常
に大変で、その大変であったということが、間に合わなかったという結果につ
ながったのではないかと思います。
大変である理由は、簡単にいうと東工大のシステムはフラットで均一な構成に
なっていないからです。 8ソケットのOpteron サーバが 650台くらいあり、
その内 360 ノードに ClearSpeed CSX600 のカードがつく、という構成です。
このシステムのややこしいところは、
-
ClearSpeed カードがついてるノードとそうでないノードがある
-
ついてるノードでも、 16 コアで1枚のカードを共有する
という構成になっているところです。 Linpack の並列化アルゴリズムは、基
本的に全てのノードが同じ構成、速度であることを前提に開発、実装されてい
ます。従って、東工大のシステムのような不均一なものの場合、それを均一な
ものにみせかけるか、または不均一なシステム用の新しい並列化アルゴリズム
を開発、実装するか、といった選択が必要になります。
しかし、行列計算というもの自体が極めて規則的で均一な計算であり、しかも
通常の並列化では行方向、列方向のそれぞれで同じサイズに規則的に分割する
ため、ノードによって能力が違うものを使うのは結構面倒です。例えば、
ClearSpeed をもってないノードが近くのもっているノードに計算ロードを少
し回す、といったことが必要になります。
しかし、そういうことをすると余計に通信が発生します。また、よほど上手く
ClearSpeed が配置されてないと完璧なロードバランスを実現するのは難しい
でしょう。さらに、ClearSpeed のボード自身、元々1枚だけ使った時の
LINPACK で理論ピーク性能の6割しか出ないというなかなかな代物ですから、
それを複数の計算機で共有して、なんてことは簡単にできるはずがありません。
もうちょっと基本的に問題なのは、 ClearSpeed ボードの理論ピーク性能が、
ホストである SunFire のピーク性能に比べて高くないことです。 SunFire 側
のピーク性能は 50Tflops 以上あり、 ClearSpeed 側は名目で 18Tflops、実
際には DGEMM で理論ピークの7割、 LINPACK で6割しかでていないので
10Tflops 分くらいしかないわけです。 Top 500 の数字では、SunFire 側だけ
でピークの 77%、38Tflops しかでていません。これに ClearSpeed の10
Tflops を足しても、通信が増えて効率がさがったりしたらかえって速度が下
がりかねません。
なお、ClearSpeed の「ピーク性能」が何を意味しているかはちょっと謎で、
昔の資料には CSX600 チップでピーク性能 50Gflops、DGEMM で 25Gflops と
書いてありましたが最近は sustained performance 25Gflops、DGEMM で
25Gflops と書いてあります。チップが変わったとは思えないので何故性能が
変わったかは不明です。ピークっていってもそれが sustain できなければ意
味がないので、昔ピークといっていたものは一体何？みたいな話です。ここで
は最近のClearSpeed の資料にそった数字にします。(ここの部分は
首藤さんの指摘 を受けて追記しました)まあ、ここはとりあえず LINPACK の話なので、
50でも 25でもなくて、行列乗算ででているチップ当り 18Gflops くらいをピー
ク性能と思ったほうが適切かもしれません。
話を戻すと、根本的な問題は、加速ボードなのですから、
-
ホスト側よりも大幅に高いピーク性能を
-
ホスト側よりも大幅に低い価格で
提供できなければ意味がない、というところにあります。
例えばの話、ClearSpeed 側の速度が 50Tflops 以上とかあれば、効率が悪く
てももうちょっとなんとかなったでしょう。この場合、1ノードに2枚とかにな
るのでノード間でロードバランスとかいった問題もなくなります。
このシステムの設計をした東工大の松岡さんは非常に優秀な人なので、
私なんぞに言われるまでもなくこのような問題があることは十二分にわかって
いたでしょう。それにもかかわらずこのような構成にせざるを得なかったのは、
単純に ClearSpeed カードが高いからだと思われます。 HIT の 2006/7/1 現
在の価格表ではカード1枚の定価が 160万円となっています。東工大が導入し
た 360枚で 6億円、仮にノード当り2枚ずついれようとしたら 20億円です。東
工大のレンタル予算がいくらかは正確には知らないのですが、年 10億はない
でしょう。とすると、5年レンタルとして予算の半分を ClearSpeed カードに
投入する必要があることになります。まあ、定価の半分としても 10億で、ちゃ
んと使えるかどうかわからないものに投入できる金額ではありません。
まあ、考えてみると、これはこの値段では当然の話です。これまで何度も何度
も書いてきたように、2006年現在では 10万円の PC で理論ピークは 12-15
Gflops であり、 LINPACKではそれに近い数字がでます。160万なら 200
Gflops、ネットワークで値段が3倍になっても 160万で70 Gflops であり、
ClearSpeedのボードより良いわけです。つまり、ClearSpeed のボードを買う
メリットは、 BG/L の場合と同じく設置面積、電力消費が少ないということし
かありません。しかし、東工大のシステムの場合は、1200枚程度まで増強しな
い限り、ピーク性能に対する寄与がそもそも少ないので面積にも電力にもたい
して影響なく、手間だけが増える、ということになっているわけです。
この話が京速計算機と何か関係があるか？というともちろんあるわけで、東工
大のシステムは、スカラのクラスタに加速ボード、という構成になっていると
いう意味で京速計算機の構想である複合型計算機というものを先取りした形に
なっています。ベクトルも導入するという話もあるようですから、そうすると
全くそのものです。 今回の東工大の結果は、少なくとも現在の東工大のシス
テム構成のようなものは、複合型計算機の構成として望ましいものではない、
ということを示しています。
まあ、これは、 LINPACK を実行するには、という話で、実際に計算センター
として運用する時には少し話が違いますが、その場合でも、加速ボードを使っ
てもホスト側で計算するのに比べて 2-3割しか速くならない、というのではユー
ザからみて意味がありません。
私が2006/6/1 に異動した国立天文台の計算機センターも汎用計算機と専用加
速ボードの両方を持つセンターになっています。導入は 2001 年度のことでも
う随分前ですが、 約 600Gflops の VPP-5000と現在 10Tflops 程度の
GRAPE-5/6 群からなるシステムです。GRAPE なので重力計算しかできませんが、
VPP よりも桁で速いのでその種の計算をするユーザのほとんど(ほとんど、で
あって全てではないのですが、、、)は GRAPE のほうを使っています。値段は、
GRAPE の側が VPP の数%だと思います(正確な数字は知りません)。現在自分の
所属であるところを誉めるのはみっともないですが、この構成では複合型に意
味があると思います。GRAPE を使える計算をしたいユーザには、 VPP を超え
る能力を提供でき、 GRAPE を使えない計算をするユーザには、GRAPE を使う
ユーザは VPP を使わないのでその分 VPP の割り当て時間を増やせますから、
どちらのユーザーにとってもメリットがある構成になります。
もちろん、絶対的には GRAPE を使うユーザのほうがメリットが大きいわけで
すが、使っているお金は少ないのでまあ計算センターとしては VPP を望むユー
ザにはそういうものを、ということになる(なった)わけです。
では、京速計算機の想定するユーザはどんなものでしょうか？
ターゲット・アプリケーション・ソフトウェア候補の選定について という発表が行われてお
り、それによると委員会があってそのメンバーは
部会長 平尾 公彦 東京大学大学院工学系研究科応用化学専攻 教授
副部会長 中村 春木 大阪大学 蛋白質研究所 教授
宇川 彰 筑波大学 計算科学研究センター センター長 数理物質科学研究科 教授
梅谷 浩之 日本自動車工業会
大峯 巌 名古屋大学大学院理学研究科 教授
加藤 千幸 東京大学生産技術研究所計算科学技術連携研究センター センター長 教授
川田 裕 三菱重工業株式会社 高砂研究所 技監・主幹研究員
北浦 和夫 産業技術総合研究所 計算科学研究部門 総括研究員
木寺 詔紀 横浜市立大学 大学院総合理学研究科 教授
阪口 秀 地球内部変動研究センター地殻ダイナミクス研究グループ グループリーダー
住 明正 東京大学気候システム研究センター 教授
泰地真弘人 理化学研究所 ゲノム科学総合研究センター 高速分子シミュレーション研究チーム チームリーダー
高田 彰二 神戸大学理学部 助教授
寺倉 清之 北海道大学 創成科学共同研究機構 特任教授
土井 正男 東京大学大学院 工学系研究科 教授
中村振一郎 株式会社三菱化学科学技術研究センター 計算科学研究所 所長
西島 和三 持田製薬 開発本部 主事
平田 文男 自然科学研究機構分子化学研究所 教授
平山 俊雄 日本原子力研究開発機構 システム計算科学センター 次長
姫野龍太郎 理化学研究所次世代スーパーコンピュータ開発実施本部 開発グループ グループディレクター
樋渡 保秋 金沢大学大学院自然科学研究科 教授
藤井 孝蔵 宇宙航空研究開発機構情報・計算工学センター センター長
古村 孝志 東京大学地震研究所 助教授
牧野内昭武 理化学研究所 ものつくり情報技術統合化研究プログラム プログラムディレクター
松本洋一郎 東京大学大学院 工学系研究科 機械工学専攻 教授
觀山 正見 自然科学研究機構国立天文台 教授・副台長
山形 俊男 地球フロンティア研究センター気候変動予測研究プログラム プログラムディレクター
オブザーバー
渡辺 貞 文部科学省スーパーコンピュータ整備推進本部副本部長・プロジェクトリーダー
高田 俊和 文部科学省スーパーコンピュータ整備推進本部リーダー補佐
というものであり、対象とするアプリケーションは
ライフ分野
名 称
候補 巨大タンパク質系の第一原理分子動力学計算
候補 タンパク質立体構造の予測
候補 血流解析シミュレーション
候補 オーダーメード医療実現のための統計的有意差の検証
候補 薬物動態の解析・予測
候補 遺伝子発現実験データからの遺伝子ネットワークの推定
次候補 蛋白質—薬物ドッキング計算
物理分野
名 称
候補 天体の起源を探る超大規模重力多体シミュレーション
候補 格子QCDシミュレーションによる素粒子・原子核研究
ナノ分野
名 称
候補 分子動力学計算
候補 ＦＭＯ 分子軌道法計算
候補 粗視化分子動力学計算
候補 実空間第一原理分子動力学計算
候補 平面波展開第一原理分子動力学計算
候補 溶液中の電子状態の統計力学的解析
次候補 低次元強相関電子系の数値繰り込み群による解析
地球科学分野
名 称
候補 地震波伝播・強震動シミュレーションモデル
候補 全球雲解像大気大循環モデル
候補 超高解像度海洋大循環モデル
次候補 全球雲渦解像結合モデル
工学分野
名 称
候補 有限要素法による構造計算
候補 有限差分法によるキャビテーション流れの非定常計算
候補 航空機解析における圧縮性流体計算
候補 Large Eddy Simulation (LES) にもとづく非定常流体解析
次候補 ボクセル手法による流体構造連成解析
というものだそうです。各分野に多少詳しい人なら、どのアプリケーショ
ンを誰が提案したかはすぐにわかると思います。本来は、このようにア
プリケーションを選定したら、
-
それぞれのアプリケーションについて、アーキテクチャとアルゴリズム
の組合せとしてどのようなものが望ましいかの検討
-
上の検討結果をベースにして、どのようなアーキテクチャ(あるいは
その組合せ) を作って、どのような計算時間の割り当てをすれば、
科学的成果をもっとも有効に出すことができるか、の検討
をして、初めてどのような計算機を作るべきかが決まる、ということに
なるでしょう。もちろん、後半の段階では、例えば天文学の成果の意義とバイ
オの、タンパク質シミュレーション成果の意義を、しかも 5 年とか10年後の計算機
ができたあとにでるであろう成果の意義を比較する、というおよそ可能
とは思えない作業が必要になります。しかし、科学技術政策における意
志決定というのはどうせそういう不可能作業をしているわけですから、
やるしかないでしょう。
もちろん、分野間の比較という不可能事をある程度回避することも可能
です。このためには、各分野でどのような構成が良いかをそれぞれ決め
て、でてきた答をさらに分野間で調整すればよいわけです。
しかし、このような評価・調整作業には時間がかかります。最初の、ア
プリケーション毎の検討も、そもそもアーキテクチャのほうがまだよく
決まっていないし、アプリケーションが選定されたのは 4月ということ
ですから、まあ、少なくとも半年、出来れば1年程度の時間を掛けるべき
でしょう。
一方、京速計算機プロジェクトとしては、 2010年度末には大体のシステ
ムを完成させる、ということになっています。プロセッサから新しく作
るのであるとまあ 5年はかかりますから、これは、既に時間が足りない、
ということを意味しています。さらにアーキテクチャを決めるまで1年と
かかかっていたのでは決して間に合いません。従って、アーキテクチャ
候補になりえるいくつかについては、既に実際に開発費をだして開発作
業を始めている必要があるわけです。
が、どうもそうなっているようには見えないわけで、その辺り、現在の
京速計算機の開発体制はどうなってるのか？という気がしなくもありま
せん。アーキテクチャ開発のほうは、
「次世代スーパーコ ンピュータ：概念構築に関する共同研究」というものが一応始まっ
たようですが、予算措置についてはまだ何も公式にはアナウンスされて
いません。アナウンスされてなくても実は決まっているのかもしれませ
んが、そうでないとするとなかなか大変です。
上のターゲット・アプリケーションのページには、
今後、これらのアプリケーション・ソフトウェアの所有者等からソースコード
等のデータを収集し、分析を行った上で、次世代スーパーコンピュータのアー
キテクチャを評価するためのベンチマークテストプログラムを作成する。そし
て、これらのベンチマークテストプログラムを用いて、本年夏までに次世代スー
パーコンピュータの複数のアーキテクチャ案についての実行予測評価を行い、
次世代スーパーコンピュータのアーキテクチャの決定に資することとしている。
となってますが、これは、まあ、その、「無理」です。まともにやるに
は全く時間が足りません。
上の「共同研究」には私の現在の所属である天文台も参加しておりまし
て、それに関係してここに書いていいかどうか判断が難しい情報もきて
います。そういうわけで、今回は、公開されている情報だけに準拠して
書くようにしています。若干歯切れの悪いところがあるのはそういうこ
とです。