今後のHPCI計画推進のあり方に関する検討ワーキンググループ(第13回) 議事録

1.日時

平成25年3月11日(月曜日)17時~19時

2.場所

文部科学省 3階 3F2特別会議室

3.出席者

委員

小柳主査,秋山委員,天野委員,宇川委員,加藤委員,小林委員,関口(智)委員,善甫委員,富田委員,中島委員,中村委員,平尾委員,牧野委員,松岡委員,村上委員,室井委員,渡邉委員
(HPCI計画推進委員会)土居主査
(HPCIコンソーシアム)藤井副理事長

文部科学省

田中総括審議官,森本審議官,下間情報課長,林計算科学技術推進室長,村松計算科学技術推進室長補佐

4.議事録

(1)「将来のHPCIシステムのあり方の調査研究」アプリケーションチームからのヒアリング・意見交換

 林計算科学技術推進室長より,資料1に基づき説明し,「これまでの議論の論点整理」を決定。また,富田委員より資料2に基づき説明。質疑応答は以下のとおり。

【小柳主査】  FSの結果は中間報告に適宜加えて,より具体的なものにしていくときに使っていくことになると思う。そのようなことも含めて,富田さんの発表に質問や意見をお願いしたい。
【秋山委員】  全体として大変な御苦労だと思う。上に五つの丸がある図を使っているが,今まで分野1から分野5という考え方で整理されていたので,これは我々にとっては重要な発想の転換になる。確かにナノとライフで同じようなシミュレーション技術が使われていたり,ものづくりでもそれを発展させたものが現場で使われていたりということで,理詰めで考えると,こうなるだろうということは分かる。ただ,もし我々が今まで分野1から5という整理で考えていたものを置き換えるのであれば,かなり慎重に作業していただきたい。この白書ではかなり大きな発想の転換を提案されているので,どう分けるのかを慎重に,特にものづくり,自動車やその設計がこの五つの分類で落ちないかなど,よく練った上でこれを出されると非常に価値があると思う。
 もう1点,防災のところで1,000個のシナリオという話があったが,独立したものを1,000シナリオやるのと,1,000倍の大きさの計算するのは本来違ってくるので,それをどこかに書いておいた方が,後の議論をするのにいいと思う。
【富田委員】  2番目の質問からですが,ここに挙げたのは一つの例で,総合防災の中でも,次につなげるような大きな計算も必要だと言われている。全系を使ったような計算が抜け落ちているわけではなく,そのような認識は議論している人たちは持っている。ただ,「京」でも地球シミュレータでもそうだと思うが,成果を出すのに一番効率が高いのは,そのコンピュータの10分の1から5分の1くらいの規模を使ってたくさんやることだと思う。ただし,それだけだと次の世代に可能性を示せない。やはり大きな計算で可能性を示すことも大切だし,大きな計算によってブレークスルーが生まれる可能性もあるので,そこは各分野の人たちも分かっていて,第3章にはそれも書かれている。
 1番目の方は,そこは慎重にやりなさいという話があるが,どのような慎重さを求められているのかがよくわからない。
【秋山委員】  例えば順番が目次と図で違うというのは慎重ではない。
【富田委員】  それは,おっしゃるとおりです。このような書き方をしたのは,例えば,産業競争力の強化というのが総合防災につながるかどうかが分からなかったので,入れ換えたようなところがある。この順番というのが,それほど大きなものになるのか。
【秋山委員】  今まで考えていた分野1から分野5を,アプリケーションの立場から再整理したことは非常に大きな仕事だと思う。もしかしたら,これで我々が今後考えていく可能性もあるので,重要だということを申し上げたかった。
【富田委員】  書き方や見せ方を含めて,慎重にしたいと思う。
【小柳主査】  産業競争力の強化という視点でこのようになったのは分かるが,社会的課題の中にも産業競争力というようなことを入れて,議論を組み立てた方がいいのではないか。
【富田委員】  一部のところには書いているが,それをもう少し頭出しするべきかどうかは,コミュニティの中でも議論を深めていきたいと思っている。
【加藤委員】  私もこの図を見て少し違和感を持った。下に書いてあるのは技術で,上に書いてあるのは課題であるが,例えばものづくりというのは,本当に技術なのか,むしろ課題ではないのかという気がする。
 それから,第2章と第3章の関係で,第2章は将来の連携課題,第3章は今の個別分野の発展形ということで書かれていると思うが,その関連を少し明確にしていただけないか。
【富田委員】  一番下の基盤となるような技術が,ものづくりに入るということか。
【小柳主査】  そうではなく,サイエンスロードマップには,今の5分野と社会科学があり,例えば基礎物理はサイエンスロードマップの一つとしていいが,ものづくりを同じような意味でサイエンス,あるいは技術も含めて言えるかどうか,ということだと思う。
【加藤委員】  位置付けとしてはむしろ上の丸に近いのではないか。そのようなことも含めて,検討いただければと思う。
【富田委員】  ものづくり分野はいろいろなところに絡んでいると思うので,ものづくり分野という形で一つ立てるのか,あるいは,いろいろな課題の中でコントリビューションしていくのか,その違いをどう理解していくかということだと思う。
【加藤委員】  そんなにすぱっと割るような分類にできないことは分かっているが,書きぶりを少し工夫していただけないかと思う。
 もう一つ,評価の方に非常に期待している。今の評価は,あるアプリに対して,検討中のそれぞれのアーキテクチャでどれだけの性能が出せるかというものだが,逆もやった方がいいのではないか。つまり,あるターゲット,スペックのアーキテクチャを決めたときに,各分野で使われている基盤的なソフトウェアのどこがボトルネックになって,どこを変えないといけないかとか,どこはライブラリにして性能を上げないといけないかとか,そのような調査までしていただけるといい。
【富田委員】  それは逆に言うと,既存のアーキテクチャがそのままいくという前提になるのか。
【加藤委員】  そうではなく,ある想定したアーキテクチャで今のアプリがそのまま走るのか,それとも変えないと走らないのか,スクラッチから開発しないといけないのはどのようなアプリなのか,そのような観点で,もし時間的余裕があればだが,検討していただければいい。
【牧野委員】  図の1番目と2番目の関係だが,2番目はある意味現状で,それを概念的に整理し直そうとしているのが,上の分類になる。3章では各分野から出てきたロードマップを束ねていて,そこからある程度統一性がある視点を作ろうとしている。だから,サイエンスと技術ではなく,どちらもサイエンスになる。
【平尾委員】  産業競争力の強化は,これから先いろいろなことを考えていく上で皆さんの理解を得ないといけないというときに,やはり上のところに一つあっていいと思う。厳密に考えるとサイエンスとか工学の分類とは違うが,むしろ産業界などからの支援を頂くという意味では,ターゲットとして掲げておく方がいいような気がする。
【富田委員】  産業競争力の強化はこのワーキンググループでも大きな問題になっているし,ほかのワーキンググループでも活発に議論されていることだと認識している。その意味では,これと並ぶような軸を設けても良いのではないかというのが平尾先生からの意見だと思うが,逆に問いたいのは,そのような形が皆さんは望ましいと思っているのかということである。
 FSの中でも,この件については議論させていただきたいと思う。今年度の中間報告書では,このような書き方をするかもしれないが,最終的にはもう少し見直しが必要かもしれない。同時に,秋山先生からあったような見せ方の問題も含めて精査していきたい。
【小柳主査】  この五つの丸はいろいろ面白いが,突っ込みどころ満載のところがある。例えば創薬を課題と言っていいのか。むしろ,長寿社会・安心社会の実現が課題であって,その手段ではないかとか,いろいろな意見があると思う。
【富田委員】  それぞれの課題については副題を設けていて,例えば創薬・医療に関しては,今後,長寿社会になっていくので,それに対する対応というようになっている。
【小柳主査】  その辺はFSあるいは関連の皆様で議論を深めていただきたいと思う。
【宇川委員】  五つをどう分類するかとか,意義付けをどう考えるかはもちろん大事だが,それよりも,それぞれのアイテムの背後に,どのような新しい段階を想定しているのかを明確にすることではないかと思う。
【富田委員】  それをやることによって,どのような質的な変化がもたらされるかという議論は精査していかないといけないし,連携と言っても,どう連携していくのか,その枠組みを含めて,来年度は詰めていきたいと考えている。
【関口(智)委員】  全体として,いろいろなコミュニティにリーチされているのはすばらしい貢献だと思うが,それでもアクセスできていないコミュニティも当然あるはずで,そこに対しては,先ほどのパブコメを求めるフェーズしかないのか。それとも前の段階で何か考えがあるのか。
【富田委員】  今回は社会科学を大きく取り上げたが,それはそもそも大学の基盤センターの課題をさらってみて,この分野はやっている人もいるし,ここに書かれた課題に対してコントリビューションが大きいのではないかということで取り上げている。これ以上に拾い上げるとすれば,今はなかなか思いつかないので,少し知恵をいただければと思う。
【関口(智)委員】  若干誤解があるかもしれないが,ここに挙げられた課題の中身の文言に関してはいろいろとコメントはあるが,大枠に関しては大体いい方向性だと思っている。その中で,これ以外を探してこいというのではなく,この中をもう少し深掘り,若しくは,もう少し課題サイドから見るようなアプローチを事前にすることは考えていないのか,そのようなところでここの皆さんが手伝えることもあるのではないかということである。
【富田委員】  ここの部分は難しいと思う。
【土居計画推進委員会主査】  日本学術会議は全ての学術分野を網羅しているので,あの場を利用するというのは一つの方法だと思う。多分,幹事会に向かってこういうものを考えているので,各分野を連ねてみんなで検討してくれ,というようなことを投げるのがいいような気がする。
【富田委員】  それが手っ取り早いですね。
【小柳主査】  それでは,ただいまの議論を参考にFSで練っていただきたいと思う。次に,アプリケーション開発の在り方を前回からやっているが,前回議論いただいた主な意見を事務局でまとめているので,林室長から説明をお願いします。

 林計算科学技術推進室長より,資料3に基づき説明。また,加藤委員より追加資料に基づき説明。質疑応答は以下のとおり。

【小柳主査】  ただいま林室長に説明いただいた資料と,加藤さんの発表を併せて,アプリケーションの開発の在り方についての議論を進めていきたいと思う。また,この結果は事務局でまとめて中間報告に組み入れていきたいので,まずは自由に意見交換をお願いしたい。
【中村委員】  エクサは2020年くらいにできるというのが大体のコンセンサスになっていたが,そうすると2016年から20年の間の議論が抜けている。加藤さんがまとめてくれているが,比較的近い将来なので,きちんと考えないといけない事柄だと思う。
【加藤委員】  エクサが動き出すまでに何をやるべきかということだと思うが,むしろその前に,そんなに大きなプロジェクトの必要はないが,公募研究を始める必要があると思う。例えば,このようなライブラリ群はこの拠点あるいは拠点群で開発するというような公募をしたり,将来のエクサのスペックは大体この辺りで分かるので,どのようなアルゴリズムが必要で,どこがボトルネックになるのかといったことを,戦略が終わる前に並行的にやる必要が,タイムスケジュール的にはあると思う。つまり,今の戦略が終わってからミドルウェアを開発し,シーズの開発を始めたら,結局,本当のアプリができるのは,それから更に2年後とかになるので,ここに空白期間ができてしまう。運用開始と同時に,世界に誇れる成果を出すためには,これくらいのスケジュール感で開発を進めないと間に合わないと思う。
【中村委員】  もう一つ,平成29年からのリーディングマシンだが,これも今まで余り具体的な話はなかったと思う。
【小柳主査】  それは,またこれから議論が出てくると思う。
【秋山委員】  今の議論には賛成で,本当にこの時期に始めないと,マシンができてからでは間に合わないというのは,皆さんもそう思っていると思うし,そのとおりだと思う。いま一度確認したいが,Linpackだけがベンチマークではないという例の論争は,ほとんどの人はここを気にしていると思う。Linpackはいいベンチマークだが,あれが目的化してしまうと,ミドルウェアの開発などは後回しになってしまうので,こういうものが先にありきだということをメッセージとして出すのはいいと思う。
 もう一つ,資料3に前回の私の発言が書かれているが,ライブラリは重要だけど仕様が合わない場合があるということを発言した。逐次処理の時代は,このような解法のものを作りましょうとか,FFTを作りましょうとか言うと合わせようがあったが,超並列になってくると,どのようにノード間で情報をやりとりするかが全く違ってくる。このような可能性も高くなってくるので,せっかくやっても全部のアプリケーションはとてもカバーできないということはあると思う。ただ,それがあっても加藤先生の提案には賛成である。
【加藤委員】  もちろん今の点は承知していて,データ構造が違うだけでライブラリは使い物にならなくなる。データ構造が違うということはメモリ間のコピーが発生するので,それにかかるコストを考えると使えなくなる。だからこそHPCIやコンソーシアムの中には各戦略機関が入っていて,そこで具体的な仕様を検討することが必要になる。それを本当は来年度中ぐらいには終えておくべきではないかと,そのようなスケジュール感を持っている。
【関口(智)委員】  最後のスライドの公募研究のところだが,これはJSTのCRESTの中で米澤先生が研究総括をしている課題とどのように違うのか,若しくは,どのように展開すると理解すればいいのか。
【加藤委員】  確かにオーバーラップするところもあるが,あれを見直すと言うと言い過ぎかもしれないが,エクサに向けたハードのスペックも,アプリのどこがボトルネックになるかという具体的な数値がまだ出ていない。その数値をまず出してから,具体的にどのようなスペックのライブラリなりシーズを開発すべきかという,全体的かつ具体的な像を明らかにした上で,こういうものが走る。ですから,米澤先生がやられているCRESTの一部は使えるだろうし,新たに開発が必要になるものもあるというように認識している。
【関口(智)委員】  むしろ,こちら側は開発という理解なのか。
【加藤委員】  ある意味ではトップダウンだと思う。それは,勝手に好きなことをやってくださいという開発ではなく,飽くまで,この時代のアプリの全体像がどうなっているかを理解した上で,それをブレークダウンして課題公募をすることになる。
【関口(智)委員】  公募の要件では,一応そのようになっていたと思うが。
【加藤委員】  現実的には,今ハードのFSが走っており,まだスペックも決まってないので無理だと思う。この中間報告が間もなく出てくるので,この作業に入れると思う。
【小柳主査】  FSで方向性は大分絞られると思うが,マシンのスペックが決まるわけではないので,上流工程が出てから下流というのも,それでいけるかどうかはかなり危惧があると思う。
【加藤委員】  私はむしろ,ハードウェアスペックはそんなに変わりようがないと思っていて,それを想定した上で,アプリ側のボトルネックが何になって,そのために開発すべきものは何であるかを検討する必要があると思う。今のFSはどちらかというとアプリの視点からハードがどうあるべきかという評価をしているが,逆にハードをある程度固定して,ハードの視点からアプリはどうなっていくかということも同時に検討する必要があると思う。
【宇川委員】  資料の4ページにあるように,コンソーシアムは開発項目や仕様に関する意見をコミュニティとして集約していくという機能があるのは疑いないが,そのときに,コンソーシアムという組織がどのような形でこれに関与していけるかは,もう少し議論が必要だと思う。今のコンソーシアムは非常にルーズな結合体でもあるので,こういったことを議論する上で,当然のバックグラウンドとして存在しているのは間違いないが,具体的な作業として,どこまで踏み込んでやるのかは,もう一段の検討が必要だと思う。場合によっては,コンソーシアムとしてのコミュニティからの意見集約より,プロジェクト的なものを走らせて,そこで集約していく方がいいかもしれない。
 もう一つは,維持管理しているアプリ,ライブラリの情報の提供で,これは当然やることだと思っている。
【加藤委員】  1点目は確かにおっしゃるとおりで,今のままでは難しいということは分かる。ただ,非常に重要なところなので,そこできちっとコンソーシアムが意見を集約するということは,今すぐにはできないにしても,将来的にはやっていく必要があるという意味でここに書いている。
【宇川委員】  できる,できないという話もあるが,やるとしたときに,どのような位置付けで,どうやっていくのかというロジスティックの検討が必要ではないかという指摘である。
【加藤委員】  まだ,かなりラフなデザインなので,おっしゃるとおりです。
【松岡委員】  先ほど加藤先生がおっしゃった中で重要なのは,アーキテクチャを規定してボトルネックを同定するということがある。我々のチームや理研の丸山チームが,ある程度共通にそれができる下地作りをやっていて,かつ,ほかのFSチームも個別のベンチマークではあるが,アーキテクチャに特化した評価基盤も作っていて,それらのスキーマを共通化することをやっている。加藤先生のおっしゃったことは,FSが終わる頃には大分道具立てができてくると思う。
【加藤委員】  道具立てだけではなくて,結果と,結果を取りまとめた上で,どのようなライブラリ群を開発すべきだということをFSの中でやっていただけるといい。
【松岡委員】  もちろんそうだが,全部をFSでやるのは大変で,代表的なものをやることになる。
【加藤委員】  大変なのは分かるが,それがないと,シーズとかライブラリといえども,本格的なアプリの開発フェーズに入れないと思う。
【松岡委員】  それは全くそうで,だから,今回のFSでそれが全部カバーできるか,ないしはポストFSとして道具立てができた上で集中的にそのようなボトルネック解析を行うか,それはやり方だと思うが,その方向に進んでいると思っている。
【加藤委員】  分かりました。
【中島委員】  前回のワーキンググループで,秋山さんから,ライブラリといっても皆が使えるものになっていない,というような話があったが,ここでライブラリと言ったときに,LAPACKやBLASのようなものを想定してはいけないということだと思う。ライブラリはC++やJavaのクラスライブラリもライブラリだし,ソースレベルのものもあるだろうし,ソースのスケルトンしかないようなライブラリもあるので,幅広く考えておかないといけないと思う。それをどこまで全体的にカバーできるかは大きな問題だと思うが,これからのHPCのためには,それを切り開いていかなければいけないと思う。
【加藤委員】  こういうところで世界に貢献するとともに世界標準を目指すためには,今おっしゃったように,どんなソースのライブラリなりミドルウェアを開発すべきかを検討して,開発を進める必要がある。ただ,戦略プログラムで成果を出すことは重要だが,全部終わってから検討を始めたのではとても間に合わないので,お金は余り使わなくても頭を使う話は早めに始めたらどうかという気がしている。
【小柳主査】  前回のまとめのたたき台では,アプリとライブラリが混然一体だったが,加藤さんからももう少し明確なイメージが提示されたので,大分議論しやすくなったと思う。中島さんのおっしゃるのは確かにそのとおりだと思うが,どこまで広げて考えたらいいかは,なかなか難しく,イメージが湧かないような気がする。
【中島委員】  難しいから,やるのだと思う。
【平尾委員】  基本的には加藤さんの言っていることに賛成で,特に国際標準を目指すというところでは,実は各国とも連携したいと望んでいる。日本からも積極的に声を上げて,国際的な連携の下で開発すべきだと思う。これまでは「京」のようなマシンがなかったので,日本が声を上げてもなかなか聞いてもらえないこともあったが,今はそうではない。立場は随分違っているので,積極的に進めるべきだと思う。
【加藤委員】  「京」を使いながら開発をしていくと,それがそのままデファクト化できて,それで日本の,少なくともその分野で地位が揺るぎないものにできるのではないかと考えている。
【秋山委員】  資料3の3ページ目に,「高性能のコンパイラ」には二つの意味があるということが書かれている。ハードウェアの性能を極限まで引き出すというのも良いコンパイラだし,いわゆる高機能言語をサポートするのもユーザからは望まれている。この発言の背景には,物理の方では共通ソフトウェア集がC++で書かれているという話があり,そのような時代になってきたのではないかということがある。そこで提案だが,高機能な言語と言ったときに,その高機能とは何かが分からなくなるので,「高機能な言語」の後に括弧書きで,「(例えばC++)」というのを入れてはどうか。HPC分野でこのことを取り扱うのはなかなか難しいとは思うが,高機能な言語として何を議論したのかがわかるように明示していただきたいという希望がある。
【小柳主査】  確かに,「高機能」というのは何を受けて,「その意味で」になるのかがわかりづらい。
【秋山委員】  このときは「使いやすく共通性が高いという意味がある」という,後者の意味だと思うが,「その意味で」もどのような議論をしたのかがあいまいである。
【小柳主査】  「高機能」というのは余りに広過ぎるので,誤解を招くと思う。
【中島委員】  昔の言葉で言ったら,高水準になる。
【小柳主査】  抽象度が高いとか,いろいろな言い方もある。
【中島委員】  何かCommon Lispとか出てこないように,例示には賛成である。
【小柳主査】  ほかにもまだ議論があると思うが,本日の議論は事務局で整理して,中間報告に加えていきたいと思う。次の議題で,HPCIコンソーシアムからの提言について,宇川委員から説明をお願いします。

(2)HPCIコンソーシアムの提言についてヒアリング・意見交換

 宇川委員より,資料4に基づき説明。質疑応用は以下のとおり。

【小柳主査】  我々の方としても,これに応えていかなければならないと思う。特に我々の考えているリーディングマシンの議論では,幾つかペンディングにした部分があるが,これに対して一つのイメージを出したということ,それから,我々の方では明確にしていなかったスケジュールを出したということもあるので,その点も含めて意見交換をしたい。
 はじめに私から質問だが,第二階層というのが重要なポイントで,「多様なニーズ」と「異なる特徴を持つ」という言葉が出てきたが,少し分かりにくい面もあると思う。
【宇川委員】  多様なニーズというのは全般的な枕言葉だが,もう少し具体的に書いたものが,3ページの下から2番目のパラグラフになる。1番目がトップマシンと似たようなアーキテクチャで,サイズ,スケールが少し小さいものというイメージ。2番目がトップとは異なるアーキテクチャで,計算科学上のニーズによっては必ずしもトップのマシンでは十分な性能が担保できないが,サイエンスとしては重要であり,かつ一定規模以上のコミュニティを支えているシステムになる。3番目はチャレンジングなシステムであり,計算機はチャレンジがあって初めて進歩していくもので,それはサイエンスのチャレンジとデュアルなものだと思う。これらの3種類をくくると,多様なニーズと言っていいであろうということである。
【牧野委員】  7ページの「開発の必要性,意義」には,「高性能計算の先駆的なハードウェア」と書いてあるが,次のページでは「単一システム」となっており,単一システムで先駆的な方向を押さえないといけないということなのか。つまり,実験的なものも含めて先駆的なハードウェア,ソフトウェアの研究開発を誰がどうやって担うのかが,これだとよく分からないと思う。
【宇川委員】  中島委員に後で補足していただくが,牧野委員は実用的なシステムと実験的なシステムは,ある程度切り分けた方がいいという意見なのか。
【牧野委員】  計算機の場合には,実験的なシステムというのが,昔みたいに小さな実験機で作れる時代ではなくなっているという理解は皆さん共有していると思う。つまり,プロセッサを作るとすると何百億円という話になってしまい,その中で,先駆的なハードウェアの開発をどうやって行うのか,ということに答えを出すのが,このワーキンググループや中島ワーキンググループに求められていることだと思う。これに明確な回答を与えていないように見えるということである。
【中島委員】  先駆的なハードウェアとしてどのようなものをイメージしているのかわからないが,1エクサを出すというのは十分先駆的だと思う。先駆的と言っても,見たことも聞いたこともないようなハードウェアを作ろうと提案しているわけではない。
【小柳主査】  ワーキンググループでは,リーディングマシンのイメージとして3通りを上げているが,コンソーシアムの中間報告は第1案というように理解していいのか。
【宇川委員】  今日の論点整理の13ページにもあるが,イメージ1とイメージ2は同じことを言っているのではないか。イメージ1はトップマシンのことだけを書いているが,イメージ2はトップマシンと,コンソーシアムの言葉で言えば,第二階層の特徴的システムが書いてある,そのような理解である。
【小柳主査】  これはアーキテクチャのFSの結論を聞かなければならないが,我々が幾つかのリーディングマシンのモデルにしゅん巡している理由は,従来のような汎用的なマシンというものが本当にあり得るのかという疑問を持っているので,いろいろなモデルを考えたと思う。コンソーシアムの中間報告を見ると,全部をカバーするという意味ではないかもしれないが,かなり汎用的なイメージを前提にしていると考えてよいか。
【宇川委員】  その辺りになると,ここで言うことの意味を定義してコミュニティとしての意見集約をしたわけでないので,私個人の考えを申し上げると,余り固定的な考えを持つのはよくないのではないかと思う。それを持ち過ぎると,何のためにFSをやっているのか分からなくなる。当然,FSは特定目的ではなく,どの範囲のサイエンス・テクノロジ・ターゲットをカバーできるのかという視点でやっているはずなので,FSのシステムに関する検討は,その意味で非常に重要だと思っている。
【松岡委員】  9ページの「ハードウェアとシステムソフトウェア,アプリケーションソフトウェアが三位一体」のところで,Byte/FLOP値(メモリバンド幅と演算性能の比)という項目があるが,これは全くそのとおりで,FSにおいても考慮が必要な点である。Byte/FLOPはメモリに限った話ではなく,ネットワークやI/O,つまりメモリ階層全体でこれが問題になる。メモリだけに注視するのではなく,システム全体のByte/FLOPの低下を追求すべきというのが次世代のリーディングマシンの在り方の一つで,その辺りを検討した方がいいと思う。
【中島委員】  世の中のアプリケーションの方々の多くが,一番心配しているのがメモリであるため,あえてこのように書いている。もちろんインターコネクトやI/OのByte/FLOP問題というのは,少なくとも同レベルでは起こるし,同レベルでは済まない可能性もあるということは認識している。ただ,このように書くとどんどん長くなるので,ここでとどめている。
【小柳主査】  同時に,同じく問題になるのは,もっと上の,例えばチップ内の記憶階層のByte/FLOPも議論になると思う。それから,先ほど富田さんの発表の中に,2から3Byte/FLOPくらいの相対バンド幅を要求している例があったが,これはいろいろな意味で分析が必要で,議論になると思う。
【加藤委員】  確かにI/Oも非常に重要で,特にメモリの方はハードとアプリの開発で,階層的なメモリをうまく使っていくことはできると思うが,個人的には,ストレージの方は絶望的だと思っている。ストレージの使い方自体を抜本的に変えていくようなことを考えないと,今後行き詰まるのではないかと感じている。
【秋山委員】  コンソーシアムのまとめは,私から見るとリーズナブルだと思う。ただ,もしWGの意見にこのまま取り入れるのであれば,第二階層については少し意見がある。第二階層の3番目にある,「将来の計算科学技術の振興につながるチャレンジングなシステム」について,アプリケーション屋として,いろいろなチャレンジングなシステムを使ってきたが,このような実験システムは第二階層には入れないでほしいと思う。例えば筑波大学で作られたチャレンジングなシステム,あれはきちっと動いて成果が出たが,安定しないようなものもチャレンジングなシステムにはたくさんある。提言としては,十分に国の予算を付けて,どんどん実験をさせるべきで,そのようなものはもっとたくさんあっていいと思うが,ただ,ここに書くのは「チャレンジング」という言葉でいいのか。
【小柳主査】  先ほど中島さんから,エクサというだけで十分チャレンジングだという程度の意味に考えてほしいということがあったが。
【中島委員】  階層の方は主担当ではないが,例えば,当時のBlue Gene/Lは十分チャレンジングであったみたいなことだと思う。製品として売れるかどうかはともかくとして,第二階層なので,そこにはユーザがいて,広い範囲の方に使っていただくHPCIの構成要素になるので,動いたり動かなかったりするのは論外だと思う。
【秋山委員】  中島先生にそう言っていただければ,信頼できます。
【宇川委員】  藤井先生からコメントあればお願いします。
【藤井HPCIコンソーシアム副理事長】  第二階層については,5ページにあるように競争原理で選ばれるものなので,その段階で今のような議論でその是非が判断されるものだと思う。だからこそ第二階層は競争的であり,全てをサポートするということになっていない。
【土居計画推進委員会主査】  コンソーシアムからの提言を,この場でどのよう扱うかは皆さんの考えによるが,以前から小柳主査にお願いしているWGとしてのアウトプットは,この段階からもう一歩先をにらんでいただきたいということである。そうでないと,目先のところだけを財務当局あるいは国会議員諸侯と勝負するようなことは,なかなか悩ましい話であり,要するに,先行きはどうなるのかという話を持っていかないと交渉は難しく,最低でももう一歩先を考えていただきたい。
【小柳主査】  コンソーシアムの中間報告にも,一定の間隔でアップグレードしていくというような文面があったかと思うが。
【宇川委員】  それに関しては土居先生がおっしゃるとおりで,私の説明では,そこは飛ばしてしまったが,次という話の背後には,やはり中長期的なロードマップ,それもサイエンスだけではなく,システム側も含めた両方からのロードマップを背景にしつつということが前提になっている。それはこの提言にもいろいろなところに書いている。
【土居計画推進委員会主査】  それはこの前の方に書いてあり,そういうことだろうと思うが,要するに,もっと具体性を持った形にしていただきたい。
【小柳主査】  ただ,次のマシンのイメージでさえ,なかなか難しいので。
【土居計画推進委員会主査】  要するに,トップレベルのものをくるくる回そうという話は,何年か前に審議会にも出し,総合科学技術会議にも出しているので,それを繰り返し出すだけでは駄目である。これから先どのような形になるかを見越した上で,目の前はこうであると言うことが必要になる。
【小柳主査】  大変重要なポイントだと思う。コンソーシアムの報告には大変豊富な内容が含まれているので,これをどのような形で我々の議論に反映させていくかを含めて,意見を頂きたいと思う。
【宇川委員】  1点申し上げるのを忘れていたが,コンソーシアムの提言の中に,情報基盤センターの役割や機能の見直し,機関連携のことも書いている。これについては,このワーキンググループでも議論を進めていただきたい。それから,今日議論されたようなアプリ開発や人材育成についても,コンソーシアムでも議論は進めるが,ワーキンググループでもよろしくお願いしたい。
【小柳主査】  先ほどの土居主査からの発言に関連して,第一階層,第二階層,第三階層というような垂直方向と,時間的な発展という意味での水平方向を両方やらなければいけないと思う。一点豪華主義で地球シミュレータを作ったら,その後,計算機が何にもなくなったというようなことになると困る。なるべく多くの方の意見を踏まえた上で,まとめに生かしていきたいと思うが,富田さんから,アプリFSの観点で何かコメントはあるか。
【富田委員】  技術開発要素に関してはB/Fだけではなく,全体を含めたI/Oが重要であり,特に私の分野で非常に困っているのは,B/Fの低下よりも,むしろ膨大なデータをどう処理するかということである。いままでも皆分かってはいたが,「京」になって初めて実感が伴ってきて,これはまずいねという話が出てきている。その意味では,計算処理能力の話も重要だが,その後の結果に持っていくためのトータルのスループットを速くすることを考えると,I/Oを含めた階層的なデータトランスファを考える必要があると思う。
【小柳主査】  我々の方はリーディングマシンというイメージで一つイメージを出そうということだったが,コンソーシアムではTier-0,Tier-1のような階層構造という考え方になっている。これをどのような枠組みで考えるのかは,我々も考えていかなければいけないと思う。
【松岡委員】  I/Oの話が出たのでもう一度申し上げると,「京」のI/O速度は大体1.何テラバイト/secくらいである。いろいろな統計や尺度から考えると,エクサフロップスマシンのときは最低限が50,できれば100テラバイト/secくらいのI/Oが必要だと言われている。「京」のバイセクションバンド幅はたかだか30テラバイト/secなので,単純に考えても「京」のネットワークよりI/Oが速くないといけない。ディスクでそれを実現しようとすると,デュアルデンシティが幾ら増えても速度は増えないので,ディスクが大体50万台か100万台要ることになる。加藤先生や富田さんの研究では,既にI/O問題が顕在化しているとのことなので,かなりフォーカスして研究開発しないといけない分野だと思う。Byte/FLOPよりむしろ大切ではないかと思う。
【小柳主査】  まだいろいろあるかと思うが,HPCIコンソーシアムの提言については,今日の議論も踏まえて中間報告に反映させていきたいと思う。
 次回はFSのシステム設計の3チームから検討状況を聞いて,リーディングマシンの研究開発について議論を進めたいと思う。また,「京」の製作を担当した富士通から,開発の波及効果などについてヒアリングを行いたいと考えている。

(3)その他

 村松計算科学技術推進室長補佐より,次回の日程(3月27日水曜日,16時,5F3会議室)を報告。

小柳主査より閉会発言

お問合せ先

研究振興局情報課計算科学技術推進室

電話番号:03-6734-4275
メールアドレス:hpci-con@mext.go.jp

(研究振興局情報課計算科学技術推進室)