■

ぼくは以前からずっと実名でやっているんだけどな。はてぶの表題をデフォルト値から変えておいた方がよかったかな？

ぼくが問題があると考える部分は「目的さえ決まれば、汎用CPUをつなげば速度はいくらでも上がる。」の部分。地球シミュレータが成果を挙げた部分は流体をはじめとする大規模な連続体力学の計算であり、CPUの能力や数よりは、TB単位で発生するメモリ間のデータ転送がハードウェア上の最大のボトルネックとなるし、そこの部分のハードウェア開発とコーディングが問題となる。グリッドがハッピーな解決かといういうと「既存技術で一番ましな解法」でしかない（私は牧野レビューをそう読んだ）。「速度はいくらでも上がる」といえるほどスケーラビリティはないのではないか。（それよりもはてぶでWebサーバと書いたので、プロバイダのバックエンドを支えている人たちからブーイングが来ないかと心配している。）

ちなみにこの手の「速度」は大抵ベンチマークテストで、通常の運用においてスペックぎりぎりの線まで常に使えているのか知らない（使えてないんじゃないかという話はそれなりに聞く）。その一方で地球シミュレータではプロセスの効率の低いジョブは掛けさせてもらえないという話も聞いている。

まきのさんのレビューではプロセッサは速いものがある、しかしデータ転送の部分で難のあるものが多いという話だ（とボクは理解した）。その中でベクトルプロセッサオンリーというソリューションは技術的、経済的にありえんだろうという話だ。しかし「だからPCグリッド」という安直な結論ではない。国立天文台みたいに目的に応じてGRAPEやスカラーとの並存もありだ。それにグリッドは少なくとも「速度はいくらでも」と安直に言えるような相手ではない。（故障の管理とかどうするんだろ？）

ただ池田氏と共有できるものはある：「大和」という印象だ。http://ud037.are.ous.ac.jp/d200709.htm#906 しかし印象の源は全然違う。ベクトルプロセッサか汎用プロセッサかという技術上の安直な二分法ではなく、どちらのハードウェア戦略を採るにしても、スケールそのものの変化に伴うコーディングそのもののパラダイム変化がないと、どうしようもないんじゃないかという実感だ。ボクが見聞きできた限りでは、その辺への目配せがもっともっとあっても良いんじゃないかと思った。（でもそれがどんなものになるか僕にはイメージできない。MPI的なものの延長上にあるのか、全部がらっと変わるのか。個人的な希望を言えば並列化は完全にバックエンドにもぐって欲しいけど。）

ところで、「京速」の目的は科学計算であり、そのためのベンチマークとなる科学計算も選定されているから、「問題は何のために計算するのかという目的であり、そのためのソフトウェアの開発」という部分は的を完全に外しているように思われる。

こうやって書いてみると100文字という制限はひどいもんだな。