スーパーコンピュータを開発する側から見た、現状認識。興味深い。
- http://blog.livedoor.jp/hkoie/archives/51127554.html いつになったら、ハードウェアの構造からソフトウェア開発者が開放されるのか。MapReduceは確かに開発者から並列実装を隠蔽したところがすばらしい。けど、開発者はそんなことに今ごろ感心していないでほしい。
問題は、スーパーコンピュータが提供する、開発用APIが低レベルすぎるんだろうと思う。大規模シミュレーションを行っている人のほとんどは、2次元(画像処理)〜3次元(分子、流体)〜高次元(量子計算など)のユークリッド空間の問題をとりあつかっている。1次元の問題はベクトル計算機でハードウェア処理できたし、プログラミングも比較的簡単だったので、メーカーがハードウェアを提供し、利用者がベクトル演算器に適合したコードを書くという分業でよかった。
しかし、2次元以上になると、2次元を単純なマトリックスとして扱ったのではいくらハードウェアを駆使しても計算量が大きくなりすぎる。そのため、2次元以上の問題の場合、スパースなデータをいかに切り分け、必要な部分だけ計算するようにする技術が必須になる。
この問題の切り分け方は、分野によって違うし、計算機のタイプによっても適切な切りわけ方が違う。そのため、各研究分野で、各計算機の仕様に応じて最適なコーディングを別個に行うような状況が生じてしまった。
何らかの形で、スパースなデータを扱う計算を一般化し、APIとして提供できないだろうか。それができないと、計算機のの規模が指数関数的に増強されるのに応じて、開発者の苦労も指数関数的に増えることになる。
過去をふりかえってみよう。計算機の性能が指数関数的に増大するにつれ、開発者の手間が爆発的に増えるのを抑え、コードを再利用し、間違いのない安全なコーディングができるように、ハードウェアの高性能化にともなってプログラム言語も進化してきた。人間がもし間違いをおかさず、無限に時間を費せるなら、今でもコンピュータの性能を最も生かせるプログラム言語はアセンブリ言語だろう。しかし、多少の性能低下を受けいれてでも、開発者の苦労とエラーをへらせるように、新しい言語が作られてきた。
では近未来にやってくるKコンピュータは?そしてその次の世代のコンピュータは、どんな言語で書かれるべきだろうか?まさか研究者にMPIやOpenMPでプログラムさせるつもりだろうか。メーカーが開発を支援してくれるとしても、おそらくその背後には人力によるチューニングが隠されているのではないかと思う。そうではなくて、はじめからハードウェアの性能を生かせるような、プログラミング言語やライブラリも平行して開発されていなければいけないと思う。そのライブラリは、これまでの計算ライブラリ(数値計算ライブラリ、行列やFFTを提供するもの)の枠を越えて、もっと実際のシミュレーションに直結したものでなければならない。
汎用のEuclid空間データを扱うライブラリを作れないかなあ。