./note060.html

ToC

59. T2K その後 (2008/3/8 --- 2008/5/28)

  東大 月額 1億2600万   69 ヶ月 140TF 5400万/TF       日立
  京都 総額 38億9600万  46 ヶ月 61    6386(4900)      富士通
  筑波 月額 4200万      60 ヶ月 95    2652            住商/Cray Japan/Appro

ということで、共通仕様のはずですが、3大学で落札したところがバラバラ、価格もノード仕様が基本的には同じなのに2倍以上の差がでる、というなかなか面白い結果になりました。前に 55 では

   ここで興味深いのは Cray Japan の落札価格でしょう。筑波大学は現行の
   VPP5000/80 のレンタル料金は月4000万程度で、東大がおそらく月額1億以上
   をもってきているのに比べると数字が小さく、京都も6000万程度のはずです。

と書いたのですが、えーと、月額で見ると京都の数字が間違ってますね。上の数字を 46 で割ると、8500万にもなるので。これは、京都が4 年契約、というのを考慮してなかったためで、推定総額40億弱から5年と思って計算したからです。すみません。なお、京大の金額総額は M9000 7 ノード 9TFを含むもので、これはいくらか不明ですが適当に 1TF 1 億としてみると、京大の T2K 分の総額は約 30億になって東大と同等か若干安い程度です。

と、それはともかく、筑波の価格は従来の VPP5000/80 と同等の 4200万で、それで 95TF を入れる、という、東大・京大と比べると結構差が大きなものです。基本的には、これは Appro のサーバを Cray Japan がインテグレータになり、契約は住商情報システムが行う、ということで、4ソケットOpteron サーバをアメリカで大量導入している実績がある Appro が安価に供給できた、ということなのだと思います。

結果的には、筑波は東大・京大と同様なノード単価であれば2倍程度の価格であったであろうシステムを、従来の通りのレンタル月額で導入した、という興味深い結果になっています。天文台の新システムは、単純に SX と XT4 の性能を合計して Tflops 単価をだすと 4000万強になって結構高いですが、まあ、その、 SX の値段分を適当に考慮すると、XT4 分は上の筑波の数字と大きくは変わりません。4ソケットノードであることを優先するか、ネットワークが高速で実績もあることを優先するか、という思想の違いはありますが、まあ、同じメーカーが関係すると同じような値段になる、ということだと思います。

JAXA は予想通り富士通の新 SPARC を使った FX1 です。Tflops 単価とかで書くとアレですが、40Gflops に対して 40GB/s と 1B/F を実現する高いメモリバンド幅をもちます。 Opteron では 2.3GHz, DDR800 として 0.35B/F なのであたりの価格では FX1 は T2K のどれよりも良い、となっており、アプリケーションの種類によっては必ずしも悪い選択ではないでしょう。

まあ、その、個人的には、アプリケーションや基本的なアルゴリズムが同じであっても、 B/F が低いほうが演算性能あたりの単価が安いのだから、色々工夫して B/F が低い機械でも性能がでる努力をしたほうが良いのではないかと思います。従来のベクトル機向けのコードが高い B/F を要求するのは、本質的には高いB/F になったとしてもベクトル化できる形にしたほうが性能がでる、というハードウェアの要求からきているもので、そのほうがアプリケーションプログラムが書きやすいからというわけでは元々はありません。

もちろん、20年もそれでやってくるとそちらが自然な思考法になって、ベクトル化に適したやり方が容易でわかりやすい、と感じられる、という面はあるし、また、並列計算でしかも多階層のキャッシュを考慮しないといけないような機械向けのプログラミングは、ベクトル化を考えないといけないにしてもあとはメモリ1階層な機械むけに比べるとはるかに複雑であるのは議論の余地はないわけですが、まあ、そうはいっても、出来合いの計算機を買ってきて使うなら、それでそれなりの性能がでるようにするのが、個々のユーザーはともかく計算機センターとしては努力すべき目標になると思います。

といっても、現状では結局アプリケーションプログラム自体の書き換えが必要で、それを個々のユーザーの努力に期待する、となってしまうとそれ以上話は進まないわけです。一方で、計算アルゴリズム自体は、例えばメッシュ計算でも一様メッシュから nested grid, さらにはアダプティブな AMR へとどんどん複雑になっていくわけで、複雑なアルゴリズムを複雑な計算機に実装、というのが急速に個人の能力の限界を超えたものになりつつあります。では、多人数のチームでそういう開発をするのか、というと、もちろんそういう方向のプロジェクトも色々あるわけですが、なかなか汎用性と効率を両立させることはできていません。

GRAPE-DR の場合には、例えば行列乗算とか、多数の粒子間の相互作用の計算といった、粒度が必ずしも大きくない(演算数がそんなに大きくない)けれども潜在的な並列性は高い(演算数と同じ程度の演算器を使うことが原理的には可能)な操作に対して、SIMD 演算器と縮約のための付加ハードウェアで実際に高い効率を出す、というのが基本的な設計思想になっています。これはこれで悪くはないのですが、その上のレベルでの並列化や、AMR 等のアルゴリズムの複雑化にどう対応するか、というのは GRAPE-DR でも明確な方向性があるわけではありません。

Previous ToC Next