すでに半年も前のワークショップだが、スライドが公開されていたので、いまさらながら閲覧してみた。
2011 Workshop on Achitechtures I: Exasclae and Beyond http://www.orau.gov/archI2011/
一通りみてみたが、内輪ネタがひどい(Murphy)のもあるし、ほとんど会社の技術的な宣伝しか書いてない(Borkar)のもあるし、スライドだけでは意味不明(Sterling)なものもあるし、色々。
Geistのスライドは”Resilience”をキーワードとして、exascale時代には今よりすべての部分(ハードもソフトも)でエラー率が桁で悪くなるので、どうすればよいかという話。ハード的に対応するのはもう不可能な時代であるから、また、OSやランタイムでどうにかするのもほとんど無理であるから、そもそものアルゴリズムをエラー前提で作る必要があるのでは、という提案。それとともに、大規模な並列計算機のシミュレーションをするためのソフトを作っている。プログラムのバグは再現できるから修正できるわけで、そもそも色々な「エラー」は再現することが困難であるからその場での対応はできず、せいぜいそれを検知して間違える前に戻ってやり直すというのが安直な解決策(checkpointing)ではある。しかし、今より大規模になるとcheckpointingをすることは事実上不可能になるので、エラー前提アルゴリズムを検討するために、アーキテクチャや計算機のシミュレーションが必要だということ。
Resnick(“Within and Above the Exascale Program”のほう)の8ページにはぐうの音も出ない正論が。
Co-Design Is Not:
- Having a meeting upfront, and then parallel working groups that then mash separate results together into a compromise implementation
- Having monthly meetings—and then mostly ignoring any changed direction (except for complaints)
『「Co-Design」ってそもそもなんなの？』というようなとぼけた疑問を今更言い出したり、議論しているようでは話にならないのは自明。9ページには”Co-Design Should”の説明がある。究極的には、十分資金的なバックアップのあるベンチャー企業のような組織を立ち上げて、一人のリーダーが責任を負い、複数のグループをまとめて全ての最終決断をする、みたいな構造にしないとまともな計算機を作ることはできない。これは、スーパーコンピューターの歴史を振り返ると結構明白である(例えばBrooks & Blaauwの”Computer Architecture: Concepts and Evolution” ( http://dl.acm.org/citation.cfm?id=548907 )を参照。またトレイシー・キダーの「超マシン誕生」を読む。いますぐ)。それが、日本で公的な資金のものとで実現できるのかというのは、大きな問題ではある。
Shalfのスライドは実際の”Co-Design”について、かなり詳細な議論をしている。ShalfはLBNLで推進されているGreen Flashという気象の問題のための計算機開発のリーダーであり、その言葉には経験に裏打ちされた重みがある。x86命令のなかで全く使われていない命令のテーブルとか、それだけでも面白い。以前Green Flashについて見たスライドでは、とにかくTensillicaのシステムでどうにかする、という印象しかなかったが、このスライドは変化が見られる。ポイントは、計算機のためのCHIPを作るの時に、一番コストがかかるのはアーキテクチャや設計自体ではなく、その色々なレベルでの検証であるということ。その解決策のひとつは、すでに検証済みのIPを組み合わせるということで、この場合でも組み合わせたシステムの検証は必要だから、そこはFPGAでエミュレーションして、設計と検証のサイクルをできるだけ短い時間で行うという方法論が示されている。そのほか、COTSは今は”commodity”ではなくて、現在は検証済みIPが”commodity”なんだというのは鋭い(42ページ)。COTSではpetascaleでもまともなシステムを構築はできないのというのは全く正しくて、それをできると言い張るのは幻想と妄想の組み合わせにすぎない。
Shalfのインタビュー記事も興味深い。 http://insidehpc.com/2010/08/12/rock-stars-of-hpc-john-shalf/
自身が計算機工学や計算機科学の勉強や研究をしてきて、その途中で天体物理学や相対論のための並列シミュレーションフレームワークの開発に関わってきた経緯を話した上で、
I remember the perspective I had when I was in each of those different roles (when in EE, I thought the scientists were all just bad programmers, and when working for the apps group, I thought the hardware architects were just idiots who would not listen to the needs of the application developers)
異なる立場というのは「計算機」側と「アプリ」側。
この分野で研究者をやるのなら、コンピューターのことは所詮1年も勉強すれば超最先端までいけるのだから後回しにして、まずはもっと時間がかかる科学や工学の考え方や現在の問題点を理解することを最初にやりましょう、という大学院教育への個人的な意見。Co-Designと無関係ですか？