京速計算機の批判の続き

池田信夫が相変わらずやっているので、真似して。

氏の批判はもうちょっと具体的になっているので、「経済」としては見るべきところがあるようになった。でも、やっぱり引用のしかたがおかしいし、「技術批判」としてはなってないのでつっこんでみる。

私の前回同様、結論に於いては違いはないんだが、池田氏のあの批判は当事者に対してあんまりなのと、ちょっと結論への持ち込み方と、引用に疑問がある。

まず、「戦艦大和」という比愈はナンセンス過ぎる。これは前回のものを読んだら良いのだが、今のスーパーコンピュータなんて、高々

煮えたぎるヤカン

すら満足にシミュレート出来ないのだ。だから、いくらかでも戦果を上げた「戦艦大和」なんかと比較にならないくらい低性能なのだ。それでもあちこちで使われ、成果が出ているのは、

領域が限定された応用分野

だからだ。

たとえば、前に「ホールのシミュレーションをして伝達関数を求め」という話を書いたのだが、これだってちゃんとやろうと思うと、「空気」とか「壁」とかの物理的な特性を計算しなきゃいけない。さらに、壁の外にはさらに壁があるし、壁は均質の材料じゃないし、空気の振動って実は線型問題じゃないし… ということで、厳密に計算しようと思えばどこまでも問題は複雑化して行く。「そんなことの影響はないでしょ」という意見もあるが、「影響はない(無視していい)」と結論づけるためには、計算してみないとわからない。とは言え、そんな計算はESくらいなチャチな計算機では非力で、まるっきりお話にならない。そういった意味では、「使えねー」ということになってしまう。

そこでどうするかと言えば、既に実験的に影響の程度がわかっているもので、影響が少ないと思うものは、積極的にモデルから外す。いわゆる

ネグる

ということをやるわけだ。壁は十分振動を減衰するから、壁の向こうは計算から除外するとか、可聴音の波長では壁素材の不均一性は無視していいだろうとか、常識的な音の大きさなら媒質の非線形性は無視しても困らんだろうとか。あるいはそこまでモデル化するんであれば、もっと大胆に波動方程式を使わなくっても、「音波は直進する」という仮定をして音線図法を使うとか。そうやってモデルを簡単にして、計算可能な領域に持って行って計算するから、既存の計算機で計算しても成果が出る。

ところが、ESが求められている世界はこれとは違う。一番の違いは、「知見がないもの」を計算しようとしているということだ。

ほとんどのシミュレーションは、基礎方程式があると共に、モデルとそのモデルの評価が存在している。基礎研究をしているところは、モデルと実験結果を比較して、そのモデルの限界とかを検証する。そうやってモデルは作られる(学部レベルでやるような「基礎方程式をいきなり離散化をして計算して満足」したようなモデルは使えない)。こういったモデル化があるから、遅い計算機でもいいわけだ。

ところが、ESがやろうとしている計算は、いまだ有効なモデルすらない世界なのだ。と言うか、

どのパラメータが結果に影響を与えるか

という、ごく基本の基本のところすらわかっていない。とゆーより、それを知ることがESでやる計算だ。「CO2の増加って本当に地球を温暖化するの?」みたいなことを検証するのが目的なわけだ。

だから、計算は限りなく細かく、モデルも限りなく基礎方程式に近いものが必要となる。いや、もしかしたらそれでも足りないかも知れない。極端なことを言えば、

計算可能性を実際に計算して調べる

ようなことになるかも知れない。そういった問題だから、どこまでも要求は高くなる。

また、そんなモデルもまだ満足に作られてない世界だから、プログラムは簡単に作っては試し… が出来なきゃいけない。モデルが正しくて後は計算するだけという状態(実用的な数値実験はそうだ)であるなら、頑張ってチューニングすればいいから、多少プログラミングにスキルが必要であっても問題にならないが、この場合はそうじゃないのだ。

だから、同じ「スーパーコンピュータのユーザ」と言っても、「後は計算が速くなるだけ」という人達と、「計算が速くないとプログラムそのものが書きにくい」という人達とでは、視点が違う。牧野氏の批判は前者に基くものなので、本人が「そんなのいらねー」という時には実に正しい意見であるが、「評論家」が引用する時にはもう一方の立場の意見を引用しなければ、公平性に欠く。

というのは、前振り。

多くのベクトル型スーパーコンピュータを支持する人達は、歴史をまるっきり忘れている。って、私も先日ベクトル型スーパーコンピュータ華やかりきし頃の数値解析の本を読み返していて思い出したことなんだが。

実は、ベクトル型スーパーコンピュータであっても、

チューニングは凄く大変

だったのだ。その頃の数値解析の本には、どうやって性能を引き出すかというノウハウについても書かれていた。計算の順序を変えたり、計算をまとめてみたりとかして、ベクトル演算器をいかにして止めないかということを考えることが重要だったのだ。

だから、それ以前の「大型計算機」で速度が出ると言われていたアルゴリズムも、ベクトル計算に不向きだと言われて捨てられてしまったものとか、改良されたものとかもたくさんある。また、コンピュータの方はそういった「本質的に苦手」な計算であっても、高速に計算出来るようなハードウェアだとかコンパイラだとかが開発された。そうやって頑張った結果、ベクトル型の計算機で速度が出せるようになり、「使いやすい」とか言われるようになったのだ。今あるベクトル型計算機が、最初からプログラムを書きやすかったわけじゃない。

ハードウェアの速度向上は、もうかなり限界だ。「ベクトル型」と呼ばれるESだって、中身は単にベクトル計算機だけじゃなくて、それがずらーっと並んで並列処理するようになっている。そういった意味で言えばプログラミングの手間とかチューニングは、クラスタ型のものと大差ないはずだ。PEが速いとかICが速いとかということはあるだろうが、それは50歩100歩だ。また、次の「京速計算機」にしたって、「ハイブリット型」とか言ってるくらいだから、中身は「ベクトル型のクラスタ」を想定しているのだろうと思う。

そういったことを考えると、世界(アメリカ)に一歩先に出るためには、ハードウェアにガンガン金をかけて、ハードウェア的に無理やり速度を稼ぐことを目的とするようなプロジェクトじゃなくて、その辺のハードウェアで作ったクラスタ上であっても簡単にプログラムが書けるようにするための、

ソフトウェア(ミドルウェア)

に金をかけるべきだ。ソフトウェアで頑張れば、ハード価格の安いスーパーコンピュータが作ることが出来るわけだから、幸せになる人は格段に増える。「FireStreamを2000個並べて1PFLOPS」は今は嬉しくも何ともないだろうが、それを上手く扱うソフトウェアが出来れば、実用的にも

たった5億で世界一

になる。これなら、「ちょっとした研究機関」なら買うことが出来るし、今からやったら次のSCに間に合うくらい現実の技術になっているのだ。どうしてもハードウェアが作りたかったら作ってもいいけど、FireStream程度のチップであれば、設計するのも製造するのも、日本のメーカにしてみればどうってことのないもので、要は「やる気」だけの問題だ。

「国産アーキテクチャ」にこだわるんだったら、それこそGRAPE(みたいなもの)に金出せばいい。GRAPEアーキテクチャで汎用の高速計算に使えるようになったら、それこそブレークスルーになる。現在のGRAPEアーキテクチャでダメなら、次のアーキテクチャを考えればいい。何にせよ、ハードウェアが無理して速度を上げないとダメだという方向からは離れるべきで、安く作れるハードウェアを必要なだけ用意すれば必要なだけ速度が出る、それでいてプログラムが書きやすいという、そういった方向の「ソフトウェア」を作るのだ。そうすればみんなが幸せになれる。

つまり、「京速計算機」が馬鹿げているというのは、それが「大艦巨砲プロジェクト」であるとか、ITゼネコン救済だとかというような問題ではなくて、

投資される資金に対しての期待される受益者の少なさ

なのだ。1000億なんて他の税金のむだ使いからすれば、ゴミのようなものでしかない(財投の焦げつきなんて兆のオーダだ)。「戦艦大和」みたいなたいそうな金額じゃない。それでアメリカに一矢報いることが出来るのなら、安いと言ってもいい。

でも、ちょっと視点を変えるだけで、同じ投資でも受益者は何桁も増やせる可能性があるものを、むざむざ捨ててしまっているというのが馬鹿げている。たとえるなら、「戦艦大和」と言うよりは、

地方債で建てた田舎の音楽ホール

の方が、イメージに近い。年に1度の「音楽祭」に町民が来るだけで、普段は講演会に使ってるだけとかって奴。昔の私の客はちょうどそんなところだった。これなら「利用者の少ない田舎の高速道路」の批判と同じ論理が使えるのだから、池田センセイでも出来るでしょ。

ソフトウェア中心のプロジェクトとなると、確かに「国家プロジェクト」としては弱いのかも知れないけれど、「成果物は全部オープンソースにするぞゴルぁ」とでも言えば、アメリカ涙目だろう。