最近の話題 2010年7月10日
１．Little Green 500でGRAPE-DRがトップ
Green 500は，その直前のTop500にランクされたシステムだけが対象ですが，より小規模なシステムを含めるため，対象システムの性能を１８カ月前の５００位以上と広げたのがLittle Green 500リストです。今回，このリストで，国立天文台のGRAPE-DRシステムが815.43MFlops/Wをマークして堂々の1位になりました。なお，2位は先週の話題で紹介したGreen 500トップのFZJのQPACEの773.38MFlops/Wです。
東大と国立天文台の共同発表によると，Core i7-920 CPUに4個のGRAPE-DRを付けた計算ノード64ノードのシステムでの測定とのことです。Core i7-920は2.66GHzクロックですから，64個のピーク性能は2.73TFlopsで，これだとLINPACKで2.2TFlops程度というのはちょっと低めかも知れませんが，まあ，おかしくない値です。これにGRAPE-DRを付けて23.4TFlopsまで向上となっているのですが，Little Green 500のリストによると，28.67KWの消費電力で815.43MFlops/Wとなっているので，LINPACK値は23.67TFlopsでないと計算が合いません。しかし，1%程度の差なので，目くじらを立てるほどの違いではありません。
GRAPE-DRシステムは512チップのシステムで21.96TFlopsを出して前回と前々回のTop500にランクインし，この時はチップあたり165GFlopsでしたが，今回は200GFlopsと書かれており，この時の330MHｚから400MHｚにクロックアップしたようです。
しかし，GRAPE-DR 1個で200GFlopsで，これが64ノード×4個で256チップとすると，ピーク性能は51.2TFlopsとなり，CPUとの合計は約54TFlopsとなります。これでLINPACK 23.67TFlopsではピーク性能の43.8%で，理論ピーク性能の80%という記述と矛盾します。もちろん，これでもピーク比率は従来の25%程度から2倍弱に改善しており，星雲や天河一号と並ぶレベルですが．．．
と書いたら，早速，牧野先生からピーク性能の80%以上はDGEMMの性能というご指摘のメールを戴きました。確かに，発表文を見返すと，「行列演算で」と書いてあり，私のミスです。謹んで訂正いたします。汎用CPUベースのスパコンではDGEMMの性能とLINPACKの差は小さいのですが，GRAPE-DRではホストのメモリが非常に小さいなどの要因があり，DGEMM性能の半分強になってしまうとのことです。
２．次世代日の丸スパコンの愛称は「京」に決定
理研は2010年7月5日に，公募していた次世代日の丸スパコンの愛称を「京」に決定したと発表しました。目標性能が10PFlopsで，日本語の単位では兆の上の京となることから，従来から京速スパコンと言われており，無難な命名です。そして，英文ではK computerという愛称だそうですが，私には，こちらはちょっと素っ気なさすぎの感じがします。
なお，一部の報道では「雷神」と争ったと書かれていますが，Risingとかけて雷神も良い名前だと思います。全く，技術的な内容の無い話題ですみません。
３．日立がPOWER7搭載のHPCサーバを発表
2010年7月9日に日立は，3.3GHzクロックのPOWER7プロセサを搭載するSR16000 モデルXM1サーバを発表しました。
これまでのSR16000はPOWER6ベースだったのですが，今回のモデルXM1でCPUがPOWER7となりました。1ノードは4チップで，クロックが3.3GHzなので，ピーク演算性能は844.8GFlopsとなり，最大256GBのメモリを搭載します。そしてこれらの計算ノード間をInfiniBand（片方向4GB/s)で接続する形態で，最大512ノードまで拡張できると書かれています。
システム自体は空冷で，バックドアを水冷するオプションがあります。
出荷は11月1日からで，お値段は個別見積もりとなっています。
４．CPU vs. GPU，PhysXのケース
2010年7月5日のReal World TechnologiesにDavid Kanter氏がCPUでPhysXを走らせた場合の分析を掲載しています。
3Dゲームで絵が写実的になると，爆発で飛び散るビルのコンクリート片などの動きがどうも嘘っぽくて気になるということになり，これらを力学的にシミュレーションして計算するということを始めた会社の一つがAgeiaという会社で す。単精度浮動小数点で並列に演算する専用LSIとソフトをPhysXという名称で売っていたのですが，ビジネスとしてはうまく行かず，結局，NVIDIAに買収されてしまいました。
そして，NVIDIAは，このPhysXを同社のGPUで動くように最適化し，CPU上でPhysXを動かすのと比較して同社のGPU上で動かすと2〜4倍高速で動作する。他社のGPUを買ってもCPUでのPhysX処理がネックとなってゲームのフレームレートは上がりませんよと言っており，デモアプリを動かすとNVIDIAのGPUを使う場合はスムーズに動くのに 対して，ATIのGPUでPhysXをCPUで動かすとフレームレートが低くて快適に動かないということになっています。
Kanter氏は，この2〜4倍の違いがどこから生まれるかを調べようとしたのですが，CPU上でのPhysXの動作を調べると，いろいろと不審な点があり，それを詳しく分析したというのが掲記の記事です。Kanteｒ氏の結論の要点は，CPU版のPhysXは浮動小数点の計算に昔々のx87浮動小数点演算を使っており，SSEの並列演算も複数コアを利用したマルチスレッドも使っていないので，CPU版PhysXは性能が低いというものです。
PhysXは32ビットの単精度FPを使っているので，SSEを使えば4演算を並列に実行できる筈ですが，それを80ビット精度で1演算だけのx87を使っている。SSEを使えば最大で4倍，まあ，少なくとも2倍は性能が上がる。さらにGPGPUで多数のスレッドで並列実行しているのであるから，CPUでも複数コアを使って並列実行すれば数倍に性能があがる筈で，CPUに対してもPhysXを最適化すれば，性能差はなくなり，CPUの方がGPUより速いことになるかも知れないということです。
勿論，NVIDIAがCPU用のPhysXを最適化しなければならない理由は無いのですが，普通にコンパイルすればSSEを使うというイマドキ，わざわざ，x87を使う 低性能コードを作るというのは，ちょっとやりすぎの感があります。
なお，PhysXと同様な物理シミュレーションプログラムを作っていたHavoc社はIntelに買収されており，HovocはIntelプロセサに最適化されていると考えられます。また，オープンソースのBulletも意図的にCPUでの実行性能を下げる理由が無いので，CPU上で問題なく動いているそうです。