Previous ToC Next

104. Blue Waters, 日本のポストペタプロジェクト(2011/8/13 書きかけ)

というわけで、スパコンでない話は 向こうに 書くことにしたのでこっちはスパコンの話です。

104.1. Blue Waters

7月、8月は色々ありましたが、まずは NCSA の Blue Waters のキャンセルが 話題でしょう。これは CPU は Power7 ベースでとっくにできていて、 日本国内でも例えば京大基研に納入されています。これはシステムは 日立ですが、 BW も基板(「畳」といわれているやつ)は SC09 で既に展示 されていて、当時の話では今頃にはもうできているはずでした。

公式の発表では

    The innovative technology that IBM ultimately developed was more
    complex and required significantly increased financial and
    technical support by IBM beyond its original expectations. NCSA
    and IBM worked closely on various proposals to retain IBM's
    participation in the project but could not come to a mutually
    agreed-on plan concerning the path forward.
ということで、「マシンのための技術はできたけど IBM による財政的、技術的 なサポートが当初の予想以上に必要になった」と書いてあります。これは一見、 コストが高くなりすぎた、と書いてあるようにみえますが、どうせここまでの 開発に莫大な費用を使ったに決まってるわけですから今になって撤退というの が単純に財政的な理由であるわけはありません。つまり、おそらく、動かせな かったのであろう、ということです。実際、単にfinancial というだけでなく techinical なサポートがこれからもまだ想定以上に必要、というのは、そう 解釈するほうが自然です。ある意味、随分正直に書いてあることに驚きます。

なお、2年前の某社についてどうということはここではいってませんのでそこは 誤解のないように。開発フェーズもだいぶ違うわけですから。

まあ、その、IBM の過去の歴史を辿ると大失敗なプロジェクトはいくらでもあ るので、そういうことが起こる、というのはそれほど驚くような話ではありま せん。大きいのの名前だけをあげれば Stretch(7030), ACS, BlueGene (BG/L じゃないオリジナルのほう)といったところで、この中で出荷できたのは 7030 だけです。

入るはずのマシンが入らなくなった NCSA は大変だとは思いますが、 IBM のプロジェクトとしてはまあそういうもので、BG/Q は 大体はできたみたいだしなんとかなるのかな?という感じです。

もっとも、6月の Top500 でも BG/Q はあまり大きなシステムになってないの が微妙に気になるところで、512チップということはおそらくまだラック半分 のシステムであり、ラック間接続は安定動作できてない、というふうに みえなくもありません。

まあ、その、BlueGene の歴史を見ると、L の前の当初計画ではなんだか難し いことをしようとして失敗し、 QCDOC をちょっと強化したくらいの BG/Lというシステムを急遽でっち上げたのが L、それをあまりいじらないで 並列度をあげたのが P だったわけで、 Q は L, P とは全く違うもの になっています。なので、素直にできてくるわけではない、ということは 想像できなくもないところです。

104.2. 日本のポストペタプロジェクト

さて、「京」でめでたく LINPACK 世界一を実現した日本としては、 次を、という話になる、というか、既に何度か書いてきたように 「京」ができてから次を、では5年は遅いわけですが、まあ、その、 何か検討がはじまっています。最初のレポートは 今後のハイパフォーマンス・コンピューティング技術の研究開発についてです。日 本のHPCのこれからの10年がどうなるかを決める極めて重要なレポートなので、 少し詳しくみていきましょう。

報告書によると、 「今後のハイパフォーマンス・コンピューティング技術の研究開発 の検討ワーキンググループ」というものが 4/13に設置されていて、委員は 以下の通りです。

  浅田 邦博 東京大学大規模集積システム設計教育研究センター教授 
  宇川 彰 筑波大学副学長・理事 
  小柳 義夫 神戸大学大学院システム情報学研究科特命教授 
  笠原 博徳 早稲田大学理工学術院教授 
  下條 真司 大阪大学サイバーメディアセンター教授 
  関口 智嗣 産業技術総合研究所情報技術研究部門長 
  関口 和一 株式会社日本経済新聞社産業部編集委員兼論説委員 
  鷹野 景子 お茶の水女子大学大学院人間文化創成科学研究科教授 
  所 眞理雄 株式会社ソニーコンピュータサイエンス研究所代表取締役社長 
  主査 土居 範久 慶應義塾大学名誉教授 
  土井美和子 株式会社東芝研究開発センター首席技監 
  中島 浩 京都大学学術情報メディアセンター長 
  根元 義章 東北大学理事 
  平尾 公彦 理化学研究所計算科学研究機構長 
  平木 敬 東京大学大学院情報理工学系研究科情報科学科教授 
  松岡 聡 東京工業大学学術国際情報センター教授 
  村上 和彰 九州大学大学院システム情報科学研究院教授 
  矢川 元基 東洋大学計算力学研究センター長 
  米澤 明憲 理化学研究所計算科学研究機構副機構長 

報告書に書いてあるように、私は5/11に呼ばれて話をしてます。そこで配布し た資料には、「委員会で各分野からの要求をまとめてアーキテクチャを決める ようなことをすると失敗する」と書きました。まあ、資料にいれただけで 話はおおむね天文からの要求、みたいな話をしたのですが。

その時に議論を聞いた印象では、一部委員からは極めて真っ当な意見がでてい たのですが議論の取りまとめ側にそれを聞く気があるかどうかは?、という感 じだったのですが、かなり実質的な議論があったようで、「議論のまとめ (1) 今後の取り組みの方向性」が以下のようになっています。

  ・ この先5年から10年程度を見据えた上で、HPC技術に対するニーズ
  と本当に やらなくてはいけない問題の設定を明確にすることが必要。 
  
  ・ 研究開発を進めるにあたっては、HPC技術を如何に活用するのかとい
  う検討を出発点とすべき。 

  ・ 解くべき問題に適したアーキテクチャで計算機を開発する必要がある。
  このため、今後のHPCシステムとしては、目的別に特徴のある複数のシス元の黙阿弥
  テムを検討していくことが望ましい。
  
  ・ エクサフロップスを当面の目標にしつつも、途中の数10ペタフロップ
  スから100超ペタフロップスをまず開発し、ハード面、ソフト面の課題を
  検証すべき。
  
  ・ ハードウェア単独の技術開発ではなく、システムソフトウェア、アプリ
  ケーションソフトウェア、ネットワーキングの開発と一体となって開発を進
  めるべき(コデザイン)。  
  ・ ハードウェア、ソフトウェア、アプリケーションの全ての面において、
  どの部分をスパコン専用に開発しなければならないのか、また、どの部分を
  日本の技術として開発しなければならないのかについて、産業界の状況も勘
  案しながら定めていくことが必要。
  
  ・ 上記により定められる技術の1つとして、プロセッサの開発に必要な中
  核技術は産業面での波及効果も大きく、我が国として取り組んでいくべき。
  高速・小型・低消費電力を実現する我が国発のマイクロアーキテクチャ技術、
  アクセラレータ 技術、システムオンチップ技術などの採択が望まれる。 

  ・ また、インターコネクト技術、ネットワーク技術の革新も望まれる。 

  ・ さらに、各利用分野の目標達成のためには、コンピュータアーキテクチャ
  やシステムソフトウェアのみならず、モデル化の再検討や新しいアルゴリズ
  ムの開発も必要。
  
  ・ 開発したHPC技術を産業界に展開し、スーパーコンピュータに限らず
  その技術を波及していくことが必要。これにより、HPCベンダーを含む我
  が国産業界の競争力の強化、ひいては我が国の国際競争力の強化につながる
  ようなシステムを確立することが必要。
  
  ・ 津波予測など緊急的に極めて重要な処理が必要な場合に、専有して計算
  するというコンピュータが必要。また、即時的な地震・津波予測のためには、
  オンラインでセンサーからのデータをリアルタイムに集めながらシミュレー
  ションしていく必要がある。センサーデータのオンライン処理やリアルタイ
  ム性を念頭に置けば、CPS(サイバーフィジカルシステム)の中核として
  のスーパーコンピュータの活用という観点が重要。
  
  ・ データの爆発を考えると、データの取り扱いが重要な開発要素となる。
  階層的なデータをうまく取り扱うプラットフォームが必要。
  
  ・ 10万並列単位のマシンでのアプリケーションの開発にまじめに取り組
  むことがエクサフロップスに行く近道と考えられる。また、超並列化をスムー
  ズに行い得るシステムソフトウェアの開発が重要。
  
  ・ HPCシステムの利用面を考え、関係府省と連携した体制を構築してい
  くことが求められる。
  
  ・ 今後を担う若手研究者、技術者の積極的な参画を得た研究開発体制を構
  築することが、人材育成の観点からも重要。
これは読んでいただくとわかるように、実際に開発していく方向を定めた、と いうよりは、委員会ででた議論を列挙した、というもので具体的な開発方針で はありません。開発方針については、

  (3)具体的な取組み 
   今後のHPC開発のあり方を具体化していくため、以下の3つの作業部会
   を設置する。まずはアプリケーション作業部会における検討を進め、取り
   組むべき課題に必要なHPCシステムとこれに要求される事項を検討する。
   この結果を受け、コンピュータアーキテクチャ作業部会、システムソフト
   ウェア作業部会が緊密に連携をしながら必要な検討を進めることとする。
   また、必要に応じ、アプリケーション作業部会とも合同で検討を進めるこ
   ととする。  

   ・アプリケーション作業部会
   主要分野の研究者及びアプリケーションソフトウェア開発者を中心に構成。
   今後必要とされる課題解決に取り組むにあたり、HPCシステムに要求さ
   れる事項を検討・整理。部会の構成及び検討の進め方については、戦略分
   野を中心としつつもこれに限定せず、また、異なる分野間の密接な連携が
   図られるようにすべきである。
   
   ・コンピュータアーキテクチャ作業部会 
   スーパーコンピュータ開発者、プロセッサ開発者、コンパイラ開発者を中
   心に構成。アプリケーション作業部会から提示された事項を達成するため
   に必要なCPUとコンピュータアーキテクチャ、データストレージ、イン
   ターコネクト、ネットワークを検討。必要に応じアプリケーション作業部
   会にコンピュータサイエンスの観点からの再検討を促したり、合同で検討
   を進める。
   
   ・コンパイラ・システムソフトウェア作業部会
   アプリケーション作業部会及びコンピュータアーキテクチャ作業部会と連
   携し、コンパイラ開発、ライブラリ開発、新規並列言語開発等も含め、必
   要なシステムソフトウェア開発の検討を行う。
で、私は「アプリケーション作業部会」のメンバーになっています。まあ、そ の、この部会構成とミッションの決めかた自体がこれでは駄目である、という のはここに書いただけではなく色々なところで主張してきたところです。つま り、サイエンスの課題が先にあって、計算機への要求は可能な技術に対する検 討なしに勝手に出せ、というのが上の委員会構成の建前になっているけれど、 それでは駄目で最初からサイエンスゴール、可能な計算法、可能な計算機アー キテクチャを全部同時に変化させて何が最適解かを考えるようなことを少しは やらないと先に進むことはできないわけで、そういうふうにやるためには 3つの部会にわけてバラバラに議論するのでは駄目でh初めから一緒にやらない といけません。

というようなことを7月末にあったアーキテクチャ作業部会の最初の会合と8月 初めのアプリケーション作業部会の最初の会合で繰り返してきたところです。 幸いなことに、同じような意見を持つ方もいて、多少はよい方向に 向かうかもしれません。但し、日程が

  (4)今後のスケジュール
  
   7月 3つの作業部会発足 
   7-9月 アプリケーション作業部会においてHPCシステムに求められる
   事項を検討・整理  
   9ー10月 アプリケーション作業部会の検討を受け、コンピュータアーキ
   テクチャ作業部会及びシステムソフトウェア作業部会の検討を進める  
   12月 3つのワーキンググループの共同作業を通じ、複数の追求すべきH
   PCシステムとこれを開発していく体制案をとりまとめ
と恐ろしくタイトで、なんだかわからないうちに元の黙阿弥にならないように 気をつけていかないといけない、と思っています。
Previous ToC Next