Saturday, 14 November 2009

HPC

京速コンピュータの予算の凍結とかがだいぶ話題になりましたが、ひさしぶりに牧野さんのblogを読んでみました。

京速コンピュータが迷走したのは「結局、何を計算するか」「使う人が作るシステムではなかったから」ってことなので、使う人を中心に仕切り直しが妥当でしょう。

何をどう使って作るかは、その時その時の流行がある。10年先の技術動向を読むのは事実上不可能だし。ベクトル型が行き詰まっていてってのも、そうだけど、

http://grape.mtk.nao.ac.jp/~makino/articles/future_sc/note042.html#rdocsect47

とかで、

「(IBM RoadRunnerの)CELLにしても、BG/x にしても、基本的な問題は製品開発サイクルが長いことです。CELLは2005年始めにはチップが動いていたわけで、あまり性能が上がらず倍精度になるだけのために3年以上かかったわけです。普通の 10年で 100倍のトレンドではその間に周りは5倍性能があがるので、始めによほど大きな性能メリットがないとできた頃には陳腐化するのは当然です。」

とか言われているんだけど、 まぁ、そういうところはあります。

でも、Cell は難しくって、うちでも、去年あたりからようやっと普通に使えるようになった感じ。それでも、僕が「こういう風に作ってね」と言っても、かなり細かいところまで詰めないと、学生では実装が難しいらしい。まぁ、あと少しで形になるっていうか、プロシンの論文書かなきゃならん...

最近は、GRAPE/DR で LinkPack Benchmark やっているんですね。仕方ないとは思うんだけど、微妙に虚しいベンチマークだったりする。うちのクラスタでも 60GFlops ぐらいまではいったはずですが、はっきりメモリネックでした。ソースの中までは見なかったけどな〜

http://grape.mtk.nao.ac.jp/~makino/articles/future_sc/note005.html#sect:vpp500

で、

「現在、NWT の高速クロスバーという方向は、 SX-8 の項でみたように行き詰まっています。後知恵で考えるなら、並列化アルゴリズムが始めから通信の負担が小さいものであれば、プログラムは再利用できたのではないか?という気がします。」

結局、通信の負担の小さい並列アルゴリズムを地道に考えていくしかないってことらしいですね。

Post a Comment