平成24年11月21日（水曜日）15時～17時10分
文部科学省 3階 3F2特別会議室
小柳主査、青木委員、秋山委員、天野委員、石川委員、宇川委員、加藤委員、小林委員、関口（智）委員、善甫委員、高田委員、富田委員、牧野委員、松尾委員、村上委員、室井委員、渡邉委員 （HPCI計画推進委員会）土居主査
森本審議官、下間情報課長、林計算科学技術推進室長、村松計算科学技術推進室長補佐
林計算科学技術推進室長より、資料1の項目3及び参考資料1に基づき説明。質疑応答は以下のとおり。
【小柳主査】 必ずしも全部の意見が一致したというわけではないが、いままでの意見をある程度分類した形になっているので、この段階のまとめとしては適当ではないかと思うがどうか。
一つ質問だが、8ページの（3）に三つのイメージがあるが、この「システム」という言葉は単数と複数の両方の可能性を含んでいると理解してよいか。
【林計算科学技術推進室長】 基本的にはフラッグシップとなるシステムといった場合は頂点を示すが、それが1台なのか2台なのかはまだ少し議論があると思う。
【室井委員】 私も汎用のマシンが望ましいと意見を出したが、［イメージ1］のように一つのマシンで全てをカバーするという意見は無かったのではないか。複数のマシンと言いつつも、いろいろな分野間の協調なり連携が大事であり、そのような体制がとれる仕組みが大事だという意見があったと思う。これに関しては私も重要な指摘だと思う。
【小柳主査】 無かったわけではなく、特にアプリ分野の人からは、そのようなマシンが欲しいという話があったと思う。ただ、エクサ時代にそれが可能かどうかという話はある。
【室井委員】 あるのは望ましいが、実際にできるのかというようなニュアンスだったと思う。
【小柳主査】 この部分はまだ最終意見になっていないが、このようなまとめ方でよろしいか。
引き続いて、今後の計算科学技術に係る研究開発の方向性について意見を伺いたい。前回までの議論を事務局でまとめているので、林室長から説明をお願いします。
林計算科学技術推進室長より、資料1の項目4 調査・検討課題「今後の計算科学技術に係る研究開発をどのように進めていくべきか。」について説明。質疑応答は以下のとおり。
【高田委員】 開発の必要性の3番目の丸について、ソフトウェアの国際性の記載については、今までの議論とニュアンスが少しずれていると思う。これはユーザの使い勝手も含めた国際性という観点からデファクトを目指すということで、必ずしもソフトウェアに特化した考え方ではなかったと思う。もう一つは、「国産以外のマシンがある程度導入」との記載について、マシンを導入するかどうかまで踏み込んだ議論はされていなかったと思う。アーキテクチャレベルで一部海外から技術導入して、国産でつくるということもあるかもしれないし、当初から国際協力でマシンをつくるということもあると思う。
【小柳主査】 ソフトウェアの国際性というのは二つの意味で、既存のソフトウェアを使うためという意味と、我が国発のソフトウェアをデファクトに近づけていくという両面があると思う。
【林計算科学技術推進室長】 これは前回中村先生が発言された内容で、国産だけのマシンだと、そこで開発されたソフトウェアが必ずしも国際的に使えるものではなくなってしまうのではないかという背景からの発言であり、ほかの国のマシンも使うことによって、我が国で開発したソフトウェアが国際的にほかの国でも使えるものになるのではないかというような趣旨だと思う。
【小柳主査】 言うまでもないが、（1）のリーディングマシンの開発は、我が国における開発という意味だと理解していいと思う。
【加藤委員】 この項目の最初の調査・検討課題は、今後の計算科学技術に係る研究開発をどのように進めていくかであり、議論のポイントではアプリなどもあるが、内容はほとんどがマシンを開発するかどうか、投資を回収できるかどうかになっている。その後の調査・検討課題で、ハードウェア、ソフトウェア、システムの要素技術、アプリの開発体制が出てくるので、見出しが整合していないような気がする。
【小柳主査】 確かに重要なポイントで、最初の調査・検討課題は下に書いてある議論より広いので、考え直した方がいいと思う。
【村上委員】 この項目は、ハードを開発すべきかどうかといった狭い範囲の議論ではなく、要するに、研究開発をどう思っているかはいろいろな選択肢があり、その中の一つとして、リーディングマシン、あるいはハードウェア、ソフトウェアの開発をどうすべきかを考えるべきだと思う。
前回のリーディングマシンの定義にもあったが、我が国が科学技術をリードするための仕掛けとして何が必要かということであり、その一つの道具としてリーディングマシンが議論されていると思う。究極的な目標としては、我が国としてサイエンスあるいはものづくりといったところでイニシアチブをとり続けていくためにはどのような施策が必要かということになると思う。そのための選択肢は複数あり、それらをまず挙げた上で、特に重要な項目について議論するのがいいと思う。
【小柳主査】 議論するときは項目を分けていかなければならない。ハードとアプリケーションの研究開発を、どうバランスをとりながら進めていくかは、次のアプリの話ともつながっている。
【宇川委員】 私はこの構成で大体いいと思うが、先ほど高田先生がおっしゃられた部分については私も多少違和感があった。ここはリーディングマシンの開発の必要性や意義を書いているはずなのに、国産以外のマシンがある程度導入されることも大切ではないかというのは、何か違う観点の話になっている。むしろ、ソフトウェアを開発する上でどういった視点が大事なのかを書いていると思うので、今後のアプリケーションの在り方の方に移せば整理できるのではないか。全体の構造まで戻ってしまうと、また議論が戻ってしまうのでやめた方がいいと思う。
【秋山委員】 ここではハードウェア、ソフトウェア、アプリケーションという三つの言葉が出てくるが、運用技術、特にスケジューリングも重要である。「京」のような大規模なシステムだと、大きなジョブをスケジューリングするときにかなり苦労している。全体の効率が5割や6割になることもあり、実際にスパコンを運用するときにはスケジューリング技術が大きなファクタになる。
日本はものづくりが得意だが、トップダウンにものづくりをするのが下手で、ハードウェアはできるが、それを実際にどう効率的に運用していくかまでなかなか考えが及ばない場合がある。このような意味において、ハードを下からつくることについては、時々警鐘を鳴らさせていただいている。
ハードウェアとアプリケーションという両極端だけではなく、スケジューリング等の運用技術も効率を左右する大きなファクタだということ認識していただきたい。また、国内開発における投資効果については、運用技術のようなことも含めて十分に目配せができるなら独力で開発すべきだし、ハードだけでそこが空いてしまうのであれば、世界中の技術を日本がインテグレートしてつくってもいいのではないかと思う。
【小柳主査】 今の点は項目5の重要なポイントの一つになっていると思う。
【秋山委員】 つくってから考えようというのが、今までうまくなかった点であり、極端に言えば「京」の利用率が半分になってしまうこともある。大胆な方法をとらない限りは、8万ノードで走らせようと思うとその前は2,000ノードくらいしか使っていないような時間帯が続くというようなスケジューリングになってしまうので、大きな問題になっていると認識している。
【小柳主査】 利用技術が大きな問題であるということは指摘のとおりだと思う。この辺は少し整理をすることにして、投資効果の議論、これもいろいろな意見があり統一した見解にまで至っていないが、この部分についてつけ加えることはあるか。
【加藤委員】 ハードウェアがまず必要だと思うが、このような研究開発に国がどれくらい投資すべきかが、ボトムラインとしては重要になる。というのは、2002年に地球シミュレータが開発され、次が2012年なのでこのようなペースでいくのか、それとももっとフリークエントにいくのか。このプロジェクトはある程度大きなものをつくり、その下方展開により民間の資金でしばらくは継続し、また10年ぐらいのスパンで更新していくという構想だったと思うが、それでいくのか。このようなポイントをここに書いてもいいと思う。
ここに書いてあるのは、リーディングマシンを開発するかどうかが書いてあるが、それが10年に1回開発するのか、20年に1回開発するのか、それとも例えば3年ごとにやるのかで、投資額が全然違ってくる。それに対して、皆さんのコンセンサスを得ておいた方がいいのではないか。
【小柳主査】 そもそもこのワーキンググループを設置したということは、従来よりペースを上げようということが前提になっていると思う。2022年にやっとというようなことではないことを期待している。
【青木委員】 開発のフェーズの期間というよりも、リーディングマシンがどのくらいのタイムスパンで必要かがまずあって、それを開発できるかどうかを議論しないといけない。開発のスパンで区切られてしまうと、世界との競争というときに難しいと思う。アプリ側としてはリーディングマシンの必要性と、それをどう確保するかを分けて議論していただきたいと思う。
また、スパコンの国内開発における投資効果については、それを理由に、だから開発するというロジックだと難しくなると思う。むしろ投資効果については付加的なものとして考えないと、何か、投資効果があるから開発するとなってしまうと、もともとのリーディングマシンの必要性と整合しなくなる気がする。
【小柳主査】 ロードマップをどうするかという議論が出たが、これも大変重要なポイントだと思う。ただ、地球シミュレータが2002年に完成して、次が2012年というのは少し極端な議論で、例えばその途中に、既に地球シミュレータより速いマシンは導入されており、原研とかTSUBAMEがあるので、それらを含めて、日本のHPCインフラストラクチャ全体が発展してきていると思う。
【高田委員】 長期的なロードマップを作成し、計画的に進めていくということは必要だが、周りの状況を見ながら毎年定期的にロールアップし、少しずつ方向性を変えていくことも、当然していかなければいけないと思う。
【村上委員】 以前、9センターと独法を合算したものをTOP500と対比させた資料があったが、TOP500の推移は大体予想がつくので、それにあわせて、我が国として科学技術分野でイニシアチブをとり続けるにはどれだけのマシンリソースを持たなければいけないかで、ロードマップはできると思う。それに応じて、その中のリーディングマシンが、それが複数であるとしても、トップクラスを維持するために何年周期で更新していくのかは、戦略的におのずと決まってくると思う。
【関口（智）委員】 ロードマップに関しては、大規模なリーディングマシンをつくっていくのか、それとも少し小型のものを複数セットにしていくのかは、どのタイミングでテクノロジリフレッシュメントをかけていくのかとセットになってくると思う。今はたまたま10年おきになっており、やはり大きなものだとスパンがあいてしまうが、その間を埋めるとすると、若干小型のものを、数年おきにテクノロジリフレッシュメントをかけていくことになる。それを、誰がリフレッシュメントをかける担い手になるかは、いろいろ議論があると思うが、そのコンセプトでかなり違ってくると思う。そこはコンセンサスが必要で、どの方向で行くのかは明確にしておいた方がいいと思う。
【秋山委員】 リーディングマシンの定義が世界トップレベルのマシンだとすると、性能は12年で1,000倍、4年で10倍になるので、10分の1の能力のマシンはこの定義から外れてくるのではないか。このような議論だけで、リフレッシュメントは4年だということが言えると思う。
【加藤委員】 開発の在り方は二つ方法があり、例えば10年周期で三つぐらいのシステムを常に開発し、それが3年ごとに出てくるというような在り方もあると思う。ただ、全体の予算はそんなに変えることができないと思うので、当然、投資の仕方は小規模になる。もしくは、10年のスパンを少し短くして、7、8年に1回大きなプロジェクトをやるという方法もある。前者はアメリカ式だが、このような考え方も含めて議論をした方がいいと思う。
【石川委員】 実際にハードウェアから開発することを考えると、今でもFSが2年走っているが、その後どのようなタイミングで選定されるのかもわからないまま進んでいる。企業でハードウェアの開発をするためには、人を集めて維持していかなければならず、そのような体制が整っていないところでロードマップといっても絵に描いた餅になってしまう。ロードマップを入れるならば、細かい体制についても提言しないとワークしないと思う。
【小柳主査】 体制というのは企業も含めた体制ですね。
【石川委員】 どうやって開発していくかになる。「京」のときもそうだが、結局、特殊な計算機をつくるということでR＆Dをかけ、だからこそマシンそのものは売れなかった。そして「高い買い物をした」というように言われる。もちろんそのために作ったのであるからそのとおりであり、しかも、それでないとお金が出せなかったという話もある。
コストパフォーマンスのことを言うのであれば、どのように開発体制をつくっていくのか、どうやってマシンを決めていくのかという筋道まで考えないと、ロードマップはつくれないと思う。
【秋山委員】 ボトムアップに考えるのは重要だが、このワーキンググループに求められているのは、HPCIの頂点たるマシンがどのようなものであるかという概念を設計することで、4年に一度ぐらいはリフレッシュしないとリーディングマシンの定義にならないのであればそのように議論して、その後でこれをやるためにはこんなにお金が必要だから無理だというような議論をすればいいと思う。
4年ごとに出して、前のマシンを捨てるわけではなく、おそらく微小な改造をしながら、二つくらいのセンターで8年周期で動いていって、それがずれているから4年ごとに出てくるというようなイメージだと思う。これが4になるのか、3になるのか、5になるのかわからないが、ここに求められているのはそのような概略設計をすることであり、ボトムアップは難しいから考えるのをやめようということではないと思う。
【加藤委員】 政策的に反映させるのがこのワーキンググループのミッションなので、そのような議論もあるとは思う。ただ、現実的に考えると、例えば10ペタは国でやったが、100ペタは会社だけでやるのか、それとも100ペタの段階から、ある程度国が投資するのか、1エクサは国がやるのか、いずれにしてもやる人がいないとできない。現に日本のスパコンメーカはどんどん人がいなくなっているので、それも含めて考えた上でロードマップを描いた方がいいと思う。
【関口（智）委員】 先ほど石川委員がおっしゃられたように、ある程度リアリティのあるストーリにしないといけないと思う。このようなマシンが欲しいと言うだけではだめで、そのために何が必要なのかを考えて計画を立てないと、次の実現可能性のところで「そうは言っても、やっぱりこれしかできないよね」という現実論が出てきてしまい、計画とつくったものが違ってくることになってしまう。その意味で、これは欲しいけれども、現実ではこういうところをターゲットにしなければいけない、というようなコンセンサスが得られたロードマップにする必要があると思う。
【秋山委員】 開発するかどうかはまだ決めていなのではないか。HPCI体制をつくって、日本の計算科学を振興することが求められているので、世界中の部品をかき集めて日本がインテグレートするだけでも、それしかないのだったらいいのではないかと思う。開発体制にこだわるのとは議論が違うと思う。
【石川委員】 もちろん開発するならということを言った。ストーリは幾つかのパターンがあると思っているが、パラメータはそんなに多くないので、理想論だけで済まさなくてもいいのではないかと思う。
開発するかどうかで随分違ってくるし、それを継続的にやるとすると、全体を考えないとできなくなってしまう。もちろんCPUから何からつくらずに、アッセンブリという話であれば、そこまで考える必要はないかもしれないが、それでも体制は考えなければならないし、その場合には基盤センター群のマシンとのすみ分けも整理する必要があると思う。
【村上委員】 今まではロードマップがなかったので、それを今回つくろうとしていることが重要だと思う。ロードマップとして満たすべき要件は、実現可能であることと競争力があることだと思う。二番手、三番手でいいのだったら、ロードマップをつくる必要はない。また、製造は企業でやるのであるから、企業の事業計画として取り入れるに足るだけの信頼性、何らかの裏づけがあるものがロードマップとして必要だと思う。それがなければ、企業としてもスパコン分野の技術者を確保しておくことはできない。「京」の次がないのであれば、そこで解散ということになってしまい、これが過去繰り返されてきたことだと思う。
我が国が将来にわたってこれだけの投資をしていくということを、ロードマップという形で言えれば、企業としても安心して投資ができるし、研究する立場としても、アルゴリズムを開発しプログラムをつくっていく上で安心感がある。そこにロードマップの意味、意義があると思うので、ロードマップをつくるのは非常に重要だと思う。
【小柳主査】 「京」のときもロードマップの議論はしているが、少し絵空事的な、全然保証のないものとなっている面があった。
【青木委員】 計算科学が重要であるというコンセンサスは得られていると思う。それに対して、どのくらい投資するかは難しい問題であり、ある程度の予算規模が決まって、それを実現するためにどういう方法でやるかという話に分けないと話が混乱してしまう。開発についても、必ずしも開発一本である必要はなく、開発と購入の組み合わせといった可能性もある。とにかく計算科学が大事で、そこに投資するという前提があるとすれば、それを実現するためにどのような条件を満たすべきか、それが実現できるのかどうかはFSなりで考えていただいて、できないのであれば違う方策を考えるというように言っていただく必要があると思う。できないとやりませんとなってしまうのが、アプリ側としても困る。
【小柳主査】 去年のエクサの議論のときからロードマップの重要性は議論してきたが、これは重要なポイントなので整理する必要があると思う。
【牧野委員】 長期的というのは、何年ぐらいの話をしているのか。5年なのか、10年なのか。
【小柳主査】 ここで議論しているのは、2018年や2020年といったオーダーの話になる。
【牧野委員】 長期がそこまでだとすると、これはつくらないと話にならないというのは自明であり、あまり議論する必要はないような気がする。
【小柳主査】 ただ、それはまたその先へつなげる議論も必要になる。
【加藤委員】 やはり2020年くらいまでだと思っている。その先は見えないので議論のしようがなし、ブレークスルーがない限りその先にはいかないと思う。
【小柳主査】 まだいろいろ議論はあると思うが、幾つか重要な論点が出てきたので、事務局を中心にまとめた上で議論をしたいと思う。
次に、我が国として重点を置くべき要素技術について、前回までの議論のまとめを室長から説明をお願いします。
林計算科学技術推進室長より、資料1の項目4 調査・検討課題「ハードウェア、システムソフトウェアについて、どのような要素技術に我が国として重点を置くべきか。」について説明。質疑応答は以下のとおり。
【石川委員】 CPUの開発は、実際のところコンパイラと組みになる。例えばCPUを買ってきた場合、その中身をどこまで開示してもらえるかはメーカとの関係で決まってくるため、結局、まともな処理系がつくれなくなる恐れがある。CPUというときには、コンパイラ技術も含めて、つくれるものならつくった方がいいという立場でいる。これは重要な点であり、今後はメニーコアになっていくため、コンパイラと一緒にやらないと性能を出すことが難しくなる。
【渡邉委員】 私もCPUを開発した方がいいと思うが、一つ目の丸はどのような意味か。世界と戦えるスパコンを買ってくればいいということならば、実際のところ世界と戦えるコンピュータを売ってくれる国は無いと思う。
【秋山委員】 それは秋山の発言ですが、僕が使うコンピュータは日本以外でも使っている。
【小柳主査】 戦えるというのは何で戦うか。別にLinpackで戦うわけではないので、この場合は、科学技術全体の成果という意味で戦うという意味だと思うが。
【小林委員】 私もハードウェアをつくった方がいいという立場だが、どのようなニーズに応えるアーキテクチャをつくるかが、システム設計の上でも重要だと思う。それがアメリカ製でも実現できるのならいいが、全ての分野がそれでかなうわけではないと思う。そういったときにはカスタム化になってしまうが、システムソフトウェアにも投資して、そのハードウェアの特徴をうまく隠蔽するようなシステムソフトウェアや、引き出すソフトウェアをつくることが重要だと思う。
【秋山委員】 要素技術としてここの項目に書いていただきたい技術が二つある。一つはスケジューリング等の運用技術で、特にこれだけ超巨大システムになると、恐らく基盤センターでやっている技術の延長上ではない部分が出てくるのではないかと思う。もう一つは、ローカルディスク、グローバルディスク、アーカイバといった記憶階層で、その間の自動もしくは手動による情報の効率的な出し入れのところが、今は少し弱いと思う。
東京工業大学のTSUBAMEについては、残念ながらCPUは日本国製ではないが、どのくらいの容量のSSDをつけるか、それをどのようなネットワークでディスクにつなぐかといった部分にはかなり工夫がある。実際にかなり大きなアプリを使っていても、SSDがついたことによって相当にアプリケーションの全体性能が上がったということがあった。そのようなところにも我が国独自の知恵を発揮できるので、計算機アーキテクチャの中でもCPUだけではないということを言いたい。記憶階層などで世界をリードする技術を我が国がつくることも可能だと思う。
【富田委員】 ここではCPUのことが主に書かれているが、ほかのコンポーネントも重要であり、特にスケジューリングの話では、ネットワークを考えなければならないし、気象・気候科学分野ではI／Oがボトルネックになってくる。そう考えると、CPUだけにこだわるのではなく、スケジューリング、ネットワーク、I／O、記憶階層などをトータルで考え、どれを重点的にやるべきかを考える必要があると思う。ただし、これはアプリケーションによる話でもあるので、FSでも考えていきたいと思う。
【小林委員】 FSのどのチームも、システム全体としてどのようなシステム構成が適しているかを検討しており、CPUだけにこだわっているわけではないと思う。
【加藤委員】 この課題の設定の仕方が、少し漠としている部分がある。今後の計算科学やエクサスケールを進める上でどのような技術が重要になるかという点と、その中で我が国が独自技術でやるべきかどうかは別だと思う。まず、全体的にどのような技術がクリティカルであり、その中で国として重点を置いて開発すべきものは何かを分けて考えた方がいいと思う。
【小柳主査】 この議論は、国としてという方が主たるテーマだと思うが、その前提に、技術全体のマップを踏まえた上でやらなければいけないというのはおっしゃるとおりだと思う。
【加藤委員】 ここのポイントは、そんなに頑張らなくてもどこかから買ってくればいいものや、既にあるものと、やはり重点を置かなければいけない部分というような話だと思う。
【小柳主査】 ここは政策的な判断を考えているので、技術的な必要性の中でどうするかという話になる。例えば、いろいろな国で、それぞれシステムをつくるときにそういうことをやっているわけで、インターコネクションだけ頑張って、IBMのワークステーションをつないだような計算機もどこかの国にあったが、そのようなこともあり得ると思う。だからCPUだけをどうするかという話ではもちろんないが、ただ、CPUも重要な議論であることは間違いないと思う。
いろいろと議論が出たので、少し整理してまとめたいと思う。
【牧野委員】 スケジューリングの話について、確かに今の「京」には問題があるように思う。同じような多次元トーラスを使っているクレイで問題が起こっているという話は聞いたことがないので、技術開発の問題というよりは、単に同じような技術を持ってくれば済むような感じもする。運用技術はもちろん重要だが、重点を置いて開発する技術というよりは、単に「京」の開発状況のおくれのような気がする。
【秋山委員】 条件が外れるとTofuのよさ使えず、「京」の性能が出せない。そのようなことを放置しているのは、ポイントとして挙げていないからだと思う。技術項目としては小さいと思うが、ぜひ残しておいていただきたい。
もう一つ、CPUの開発ができるならば、するべきだと私も思うが、CPUはマイクロアーキテクチャレベルで10年くらいしか持たない。それをスクラッチからつくるとすると、10年ごとに国家プロジェクトでマイクロアーキテクチャからつくらないと競争力がなくなる。それを本当にやるのかというのは、項目として書いておいてほしい。
【牧野委員】 IBMも結局はそれをやっていて、Blue Gene系では全く違うマイクロアーキテクチャを持ってきている。それと競合するためには、少なくとも同じことをしていかなければならないということは、書いておいていただきたい。つくるなと言っているわけではなく、つくるならそれなりの決心が要ると思う。
【宇川委員】 ここには、つくれるものならという願望がたくさん書いてある。それを実際にやるとすると、根本のところまで立ち戻った開発が必要になる。それを整理すると同時に、どうやったらそれができるようになるのかを考えなければいけない。それはここでは書き切れないし簡単な解決はないと思うが、この項目で一番大事な観点だと思う。どうやって実現するのかを考えると、国として何を大事と思って投資をするのかというところにも絡んでくるので、堂々めぐりの議論になってしまうが、開発が大事だというのであれば、それをどうやって実現していくのかという観点も、やはり必要なのではないか。
【小柳主査】 要素技術の話はここで区切りとして、続いて、今後のアプリケーションの開発の在り方について議論をしたいと思う。前回までの議論のまとめについて、室長から説明をお願いします。
林計算科学技術推進室長より、資料1の項目4 調査・検討課題「今後のアプリケーション開発の在り方についてはどう考えるか。」について説明。質疑応答は以下のとおり。
【高田委員】 このアプリケーションについては、開発を担う人材と、開発されたアプリケーションを利用する人材という二つがあると思う。開発した人の将来のキャリアパスの問題なども考えていかなければならないが、開発した人がアプリケーションの方向にもキャリアを広げていけるような形で考えていくことが望ましい。ある面では深くやる人も必要だとは思うが、つくる人と利用する人を完全に分離すると行き詰まってしまうと思う。
【松尾委員】 現状の「京」については、「京」で性能を出せることが利用の条件になっている。より一般的な意味で、広く使う人が増えるためには、ライブラリやミドルウェアといった間に入るような仕組みをきちんとつくっていく必要があると思う。特殊な人が特殊な状況のためだけに使う特殊なマシンで、一般の人は全く恩恵をこうむらなくなってしまうということはありがちで、「京」がそのような傾向にあるように思う。もっと広く使えるということを念頭に置くべきだと思う。
【小柳主査】 今の話はアプリケーションソフトの話か、それともシステムソフトや、ツールのことか。
【松尾委員】 ツールなどです。普通の人が使うときにも使いやすいように、また開発する人が特殊なことを知らなくてもつかえるようにすれば、普及にもつながると思う。
【牧野委員】 今後のアプリケーション開発が今よりも大変になるという前提で書いてあるが、そもそもそうであってはいけないのではないかということを調査・検討した方がいいと思う。「京」ではMPIで並列化が必要であり、そのときには三次元トーラスやメモリ階層のことを考えないといけない。一次キャッシュが2wayしかないといったことまで考えないと性能が出ないが、このようなことをアプリケーション開発の人たちに要求しなくてもいいような技術開発を考えてほしいと思う。
【小柳主査】 大事なポイントではあるが、分野が広がったり、だんだんと複雑なシステムを対象にするアプリになってくるので、難しい要素を含んでくるのはある程度仕方がないのではないかと思う。
【牧野委員】 日本に限らず、計算機が複雑になってきてアプリケーション側の手に負えなくなってきているということがある。今年ゴードン・ベル賞を取ることができたのも、このような背景があると思う。
【秋山委員】 今後の方策に書くには少し過激かもしれないが、スパコン上でのアプリが、パソコンからシームレスにスケールアップしていけるのが理想である。私の知っている分野は限られるが、例えば昔は一つか二つの大きなプログラムで仕事をしていた方が、今では7個、8個、下手すると10個以上のソフトウェアを組み合わせて作業をしていて、そのボトルネックになっているところを大型化したいという話があった。それはスーパーコンピュータでないとできないような計算量であるが、ほかのものと接続して問題を解いているので、FORTRANでつくっても、これに接続する部分を全て書きかえることがなかなかできないということがある。このように、入出力が完全互換になっていることが求められており、パソコンやワークステーションからシームレスになっていけば、ユーザの裾野は広がると思う。
【小柳主査】 シームレスを二つの概念で使っていると思うが、同一のソフトがパソコンからスパコンまで使えるという話と、インターフェースが共通で、つないで作業ができるのと両面あると思うが。
【秋山委員】 外から見て互換でさえあればいい。パソコン向けにつくったソフトが、そのままバッチ処理で「京」に流されたら大変迷惑だと思う。それは、中身を全部つくり直すものだと思っている。
【村上委員】 アプリケーションの開発については、高田さんがおっしゃっていたように、利用者の視点でもう一度考える必要があるのではないかと思う。HPC業界を除くIT業界は、この10年、20年でものすごく使い勝手がよくなったと思うが、スパコンに関しては20年前とさほど変わっていない状況にあるのではないかと危惧している。
アメリカ辺りでは「HPC in the Cloud」ということで、我々がクラウドのアプリケーションを使うのと同じような感覚でHPCアプリケーションが使えるというようなキャンペーンが聞こえてくる。SaaS（Software as a Service）、あるいはデータそのものを含めて、Data as a Serviceみたいなものがクラウドから提供され、それをユーザが使う。いろいろなツールがクラウドの中に用意されていて、必要なツールを連携することによってマルチフィジックス、マルチスケールができ、ユーザの求めるソリューションが得られるようになる。ユーザの生産性向上のためには、単なるハードだけではなく、どうアプリケーションをつくっていくかを考えないと、アプリケーションを含めた投資効果の向上は達成できないと思う。
【加藤委員】 産業利用を考えたときには、ハードウェアも含めて、アプリが使いやすい環境にしないといけないというのは重要な点だと思う。ただ、一番バックボーンにあるアプリそのものは、誰かが開発しないとつなぐだけでは使えない。それを誰がどう開発するかについては、その人たちにどこまでハードウェアの知識を求めるかが重要な観点になると思う。そうしないと、先ほど松尾さんが言ったように一部の変わった人たちだけしか使えないようなことになってしまい、また、それは小柳先生が言われたように教育の話にも関連してくる。特にメモリ階層をどこまで意識させるかがポイントになってくると思う。
【小柳主査】 アプリの維持管理についてよく言われることだが、大学やJST、科研費などでソフトが開発されても、結局、お金が切れたらそのままお蔵入りしてしまうことがある。このようなことを重ねていったのではアプリソフトは育たないのではないかという指摘がされている。それをどうにかしようという動きも、私を含めていろいろあるが、先立つものもあってなかなか難しい。加藤さんなどはいろいろ経験を積んでいると思うが。
【加藤委員】 うちのアプリも基本的には産業界で展開することによって残すということを考えているが、いきなり全てのソフトウェアでそういうことをやるのは難しい。必ずしも国が多額の投資をしなくても、コミュニティの財産としてアプリが発展するような仕組みが日本にも要ると思っている。
そんなに大規模な計算ではないが、流体ではOpenFOAMというソフトウェアがかなり使われている。もともとはISVだったが、それをGPLライセンスに変えることによってコミュニティの中で爆発的に発展してきたという経緯がある。開発者アプリが発展していくような観点でも考えるべきだと思う。
【富田委員】 アプリ開発は開発者が最初のユーザであり、そこできちんと成果を出さないと浸透しないと思う。つまり開発する人とユーザが最初の段階で乖離している状態では、幾らソフトウェアをつくっても誰も使わなくなる。これは人材育成にも関係することだと思うが、開発者が自分自身でそのソフトを使って、サイエンスをやるという人を育てるべきだと思う。
【加藤委員】 我々のソフトウェアは産業利用が大前提なので、開発者が勝手に開発スケジュールや開発項目を決めるのではなく、ユーザと何度も話をして本当にこういう機能のソフトウェアを開発すれば使ってくれるというところまで詰めた上で開発している。開発者としては開発したい機能があっても、ユーザからそれは二の次でいいよみたいなものは開発しなかったりしているので、ある程度はそういうことも必要だと思う。もう一つはニーズだけで引っ張るのではなく、シーズで引っ張るという側面も重要であり、そのバランスをソフトウェア開発全体としてどうとっていくかがポイントになると思う。
メンテナンスについても、我々は現在7本のシステムを開発しているが、そのシステムの特徴、分野にあわせてベンダにほぼ担いでもらうようなソフトウェアから、コミュニティでGPLライセンスにして育てていく、そのためのポータルサイトをつくったり、各ソフトウェアにあわせたやり方でやっている。分野ごとにフェーズが違うので、それに応じた維持、普及の体制をつくるべきだと思う。
【善甫委員】 普及しているアプリには、コミュニティなどをとおして必ずフィードバックする仕組みがある。それにはリーダーシップが必要で、そのソフトにかけて、ライフワークとしてずっとやっていく人が要るはずである。今の日本のアプリは、開発したら興味が別のところに行ってしまい、それで終わってしまう。そうではなく、もちろんビジネスの方に移るということもあるかもしれないが、これを一生やるというようなやり方があるのではないか。その意味でも、フィードバックする仕組みが必要だということをどこかに入れておく必要があるのではないかと思う。
【渡邉委員】 善甫委員や加藤委員がおっしゃるのは、ものづくりという分野だからだと思う。先ほど富田委員がおっしゃったのは気象・気候分野であり、そこではやはり論文で評価される。それに対してユーザがいる分野とは少し違うと思う。
【善甫委員】 私は同じだと思う。大きなユーザがいるところでも、信用できるソフトかどうかはやはり結果論になる。これは信用できるか、できないか、成果が出るか、出ないかはそこにあると思う。
【富田委員】 最初の信頼性は、やはり開発者がつくるべきだということですね。
【小柳主査】 いろいろと議論はあるが重要なポイントであり、確かにコミュニティの性質によって多少違うことはあると思う。
次の国際協力についてはいままでほとんど議論していないが、先週のSC12で国際協力に関するBOFをやったので、石川さんから報告をお願いします。
【石川委員】 先週水曜日の昼にBOFセッションがあり、DOEのBill Harrodとアルゴンヌ国立研究所のPete Beckman、日本側は文科省情報課の林さんと私がオーガナイザとして出席した。7月の日米科学技術協定の実務者レベルの委員会で、システムソフトウェアの開発で国際協力をしようということになり、具体的な話は今後詰めるという話になっていたが、その一つとして、まずはBOFをやることになっていた。
これは標準化をテコにして国際協力をしようということであるが、あまり標準化を前面に出すと研究が進まなかったり、イノベーションの話ができなくなってしまうので、注意深く進めるべきだということになっている。そのときに幾つか例を挙げており、標準化の前の段階で、APIのデザインといったことをしていこうという話から、FSのアプリチームでやっているミニアプリなどの情報を集約してやっていくという話、またMPIのような技術についてはスタンダード化していこうという話をした。
会場からも意見を募っており、コラボレーションのためのインフラストラクチャが必要だとか、いろいろなデータのシェアリングが重要だとか、ベンダとの協力が不可欠ということ、スタンダードとそうでない部分との折り合いをどうつけていくかが重要だといった意見があった。ロードマップについてもどうしていくかという話があったが、特段反対意見はなく、やっていくに当たってはいろいろな問題があるという話で終わっている。
また、来年3月18、19日にFSの国際ワークショップを考えているが、そのときに、今後のシステムソフトウェアの研究開発におけるコラボレーションについてドラフトのプロポーザルをつくりましょうという話になっている。その上で、6月のISCでワークショップを開こうという話になっている。
【林計算科学技術推進室長】 石川先生から説明があったとおりで、7月の段階では協力を目指してどういうことができるかを議論していこうということになっており、その具体化の一つとして今回コミュニティの意見を聞いた。更に3月に向けて中身を詰めていって、6月にワークショップを開催するという流れになっている。この分野での国際協力は長い間なかったので、ある意味手探りで進めているという状況になっている。
【小柳主査】 国際協力に関してなにか意見があるか。
【宇川委員】 意見というより論点の整理になるが、今動いているのはシステムソフトに関する国際協力で、もともとはIESPだと思うが、日本とアメリカでやっていこうという話である。計算科学技術という観点からすると、それと並んでシステムができたときにそれを使った研究における国際協力がある。例えばアメリカのスパコンを日本の研究者が使うとか、あるいは日本の設備を世界の人たちが使うとか、そのような枠組みをどう考えていくのかは、また別の視点だと思う。その論点を整理しておかないと、何を議論しているのかがわからなくなると思う。
【小柳主査】 利用の方の国際協力は項目5のポイントで、ここではハードウェア、システムソフトウェア、アプリ開発といった協力を中心に考えていると理解している。
【宇川委員】 それであれば、そのことが明確になるように書いた方がいいと思う。
【小柳主査】 わかりました、計算科学技術に関する国際協力と言うと、少し広過ぎるかもしれないので、言葉つきを少しはっきりした方がいいと思う。
【秋山委員】 そうすると、HPC技術といった表現になるのか。
【小柳主査】 これも非常に広い語義を持つ。
【秋山委員】 計算機科学だと思って、ずっと発言を聞いていたが。
【小柳主査】 どちらかというとそうです。
【石川委員】 今紹介したのは、完全にシステムソフトウェアで、かつ、結構下の方の話になる。DOEがBOFのときに言っていたのは、アプリケーションは競争だということである。システムソフトウェアに関してはDOEもそんなに予算があるわけではなく、開発したものを維持できないので、国際協力でつくった上で企業がそれをメンテナンスしていくような仕組みがないと困るというようなことを言っていた。向こうから見るとアプリケーションとハードウェアは競争という認識だと思う。
【林計算科学技術推進室長】 秋山先生の意見に対してですが、必ずしも計算科学の国際協力をここで除いているわけではなく、計算機科学にしろ計算科学にしろ、国際協力はこの項目になると思う。先ほど小柳先生の方がおっしゃられた話は、例えば外国の研究者が「京」を使いたいとか、日本の研究者がアメリカのコンピュータを使いたいといったような、単に利用、運用の話だという整理になると思う。
【秋山委員】 これはすごく微妙な話で、よく議論しないと間違うといけない。アプリの立場からいうと、「京」の資源のほんの一部分を、日本のトップサイエンティストが、海外のトップサイエンティストとの共同で利用できるようにすれば、日本のサイエンティストにも大きなメリットがあると思う。
日本は超巨大計算を可能にするためのノウハウを持っているため、そのような「京」の経験を交渉の武器にして、海外の研究グループと組んで、そこの仲間の中に入っていくということがいろいろな分野でできると思う。課題の審査は厳しくしないといけないが、使うだけだから排除しようというのはすごくもったいないと思う。
【小柳主査】 「京」にしてもHPCIのほかの施設にしても、基本的に研究者であれば、海外の利用もオープンになっている。
【秋山委員】 ソフトがそのまま走らないので、チューニングなどはノウハウのある日本側のチームがやるような協力もあり、共同で、例えばデータを処理するといったことも生まれてくるのではないかと思う。
【高田委員】 国際協力の目的は幾つかあると思うが、一つは、それぞれの国でできないものを力を合わせてつくるということがある。二つ目は、各国で同じような開発をしているので、お互いに無駄な開発投資を減らすということ。三つ目は、世界の幅広いユーザにとって使い勝手がいいもの、共通で標準的なものをつくっていくこと。そして最後は、人材を世界共通で育てていくということがある。結局、狭いコミュニティの中だと、先ほどのキャリアパスの問題もあるが、ある意味でモチベーションを上げていくとか、いろいろな問題、関係も考慮した上で、そのために国際協力をしていくということになると思う。目的をシェアできないと国際協力にならないので、どのような目的でやるのかを議論しないといけないと思う。
【石川委員】 システムソフトウェアの上でアプリケーションが動くので、いろいろな方言のシステムソフトウェアをつくるのは無駄になるし、ユーザ側でも、一つではなくて二つか三つだけ残っていたとしても、それぞれにつくらなければいけないという無駄が生じる。また、国際標準によってベンダはそれに乗りやすくなるので、企業と一緒にやっていかなければいけない。一方で、企業の論理で自分達の都合のいいものを入れてきて、性能が出なくなってしまうといった問題もあるので、理想的なことはあっても、うまくいくかどうかはなかなか難しい。ただ、目指すところはコストを下げることと、ユーザに対してポータビリティを提供することだと思っている。
実際に進めるときに、アメリカはDOEの研究機関があり、そういったアクティビティのボディになるが、日本でボディがつくれるかどうかは非常に難しい。大学でできるかというと、本当にスタンダードな話になったときは専任でやらなければできないようなことが出てくるので、それは難しく体制にもかかわってくることになる。
【小柳主査】 全部の項目をみておきたいので、項目5に入りたいと思う。室長から資料の説明をお願いします。
林計算科学技術推進室長より、資料1の項目5及び参考資料2を説明。質疑応答は以下のとおり。
【小柳主査】 利用の問題については、特にスパコン利用の促進と成果創出のための運営や利用環境の在り方ということを中心に議論したいと思う。ただし、ここは「京」の文句を言う場所ではないので、一般的な枠組みで議論していきたい。
【高田委員】 項目4までの議論は、どちらかというと計算科学技術、科学技術としての成果だったと思うが、利用の在り方では科学技術の成果はもちろん大きな柱ではあるが、もう一つ、社会への還元がとても大事になってくる。その意味で、防災といった面でも社会に還元していくし、産業競争力をつけるというのも社会への還元の一つだという位置付けで、利用の在り方や産業利用を考えなければいけない。社会還元という視点で見ると、多様な価値判断、成果の定義が必要になってくると思う。産業利用ではもともと社会還元で求められる要素が科学技術分野とは違うので、議論の前提として改めて理解いただきたい。
【小柳主査】 項目1から4までが忘れていたわけではないが、あくまで、その前提のもとで議論をしていきたいと思う。
【村上委員】 前の議論のアプリケーション開発のところでユーザ視点という話をしたが、今後もこのような使い方が続くのか。というのは、今のマシンリソースということでは「京」は十分考えられた制度だが、今後ともこれが続くかどうかというところが､大きなポイントだと思う。
【小柳主査】 続くというのは、どのレベルの話なのか。つまり法的な枠組みの話なのか、ユーザ支援といった話なのか。
【村上委員】 ユーザ視点として、今後もこのようなインターフェースで満足してHPCのアプリケーションを動かしていくのかどうかだと思う。つまり、昔ながらのセンターにおけるスパコン運用の延長線上では、使いたいときに使いたいだけのマシンリソースを使えるという形にはならない。先ほども言ったように、HPC以外のITでは、所有はしなくても使いたいときに使いたいだけのリソースが使えるようになってきているのに対し、昔ながらの課題申請をして、認められて、使える時期に使えるマシンリソースを使うというようになっている。それは必ずしも使いたいときに使えるようになっているわけではなく、世の中の、当たり前だと思われているITの使い方とは違っている。ユーザは我慢してこれを使っていくのか、もう一つ飛び越えてパラダイムシフトを起こすのか。そうすると、用意しておかなければならないマシンリソースも当然変わってくるし、システム構成もネットワークも変わってくる、また、システムソフトウェアのつくり方やスケジューリングのありようも変わってくるので、ユーザから見たときの不満度もまた変わってくると思う。
【関口（智）委員】 ここでの議論は、リーディングマシンというものに対して、雲の上にあろうが手前にあろうが、誰かが何らかの形で最適化のチューニングなり、何らかの努力はしており、それをどういう形で共有するかというモデルの違いなんだと思う。その意味で、今先生がおっしゃられたような大変な作業は誰かがやっていかないと、結局その能力は発揮できない。それがユーザサイドなのか、開発サイドなのかというところは当然議論があると思う。
一方、そのようなトップノッチのマシンを使う話と、もう少し裾野を広げていくような使い方、ユーザエクスペリエンスをより重要に考えている人に対しては、また違うタイプのシステムになると思う。このような議論はワーキンググループよりも、むしろHPCIコンソーシアムないしはHPCIのインフラストラクチャの方で議論しており、HPCIの裾野をどのように広げていくのか、また商用クラウドなどとどう連携していくのかといったところも念頭に置いて、今のHPCIのインフラストラクチャは設計されているのだと理解している。ただ、今はまだ第一ステージなので、全てが実現されているわけではないが、「HPC in the Cloud」というようなコンセプトは、むしろそちら側で進んでいると考えていいと思う。
【宇川委員】 関口さんの発言は言い過ぎではないか。HPCIの方でも利用のやり方はまだ課題申請の枠組みでやっている。それを村上さんの言うようなところまで持っていくのは、まだかなり距離があると思うし、また、そのような議論までされているわけではない。
【秋山委員】 例えば、これだけ大きな施設を民間企業がつくったら、それをどう利活用していくかを考えるセクションがあり、通常の使い方のほかにも、様々な利用形態でアウトリーチで使うとか、ユーザの増加などを日々考えている人がいる。「京」の共用の枠組みという図を見ると、恐らく登録機関がそのようなことを考えるといいと思うが、法定業務に入っているのは、課題選定と選定された人の支援であり、必ずしも営業活動をして利用者を増やすという機能は書かれていない。その中で、パソコンからシームレスに使えるとか、普通の大学生でも使えるようにすることを日々考える人というのが、国のスキームの中にはどこにもないのではないかということを心配している。
例えば、SPring－8の共用はビームラインをつくればよく、後は時間管理が主になると思うが、計算機の共用は難しい。だからこそ、そのようなセクションが必要なのではないか。
【関口（智）委員】 先ほどの宇川先生の発言について、今回できてきているものの議論の中では、石川先生にずっとリードしていただいて、まさに商用クラウドの観点を入れた上で設計されているし、それが概念として入っている。それがなければ、僕はあそこのメンバーに入っていなかったので、そこのところは理解をしていただきたいし、事実と違うということは申し上げておきたい。
【宇川委員】 少し別の観点で発言したいのだが、SPring－8の場合には、提供されているリソースに対して、ニーズの粒度が小さいと思う。ニーズの粒度に対してリソースが十分あれば、クラウド的な運用で対応できるし、後は技術的な問題になるのだと思う。しかし、スパコンや加速器の場合はリソースに対してニーズの粒度が非常に大きいので、必要なときに必要なリソースが使えるというような運用は難しいのではないかと思う。非常に大きなリソースを必要とするところと、小さな粒度でたくさんの人が自由に使えるというところを分けて考えないといけないのではないかと思う。
【小柳主査】 重要な問題だと思うが、先ほど秋山さんから指摘いただいたように、例えば「京」らしいジョブを走らせようと思うと待たされるばかりで、どのように運用するかは私も多少心配していた。
【秋山委員】 単にスケジューリングがうまく詰まらないというだけではなく、物理的な三次元形状を指定したものは、わりと上手く入るが、それを外して一次元でいいと言った途端にTofuのよさが使えなくなってしまう。スケジューリングの情報をオープンにしてもらえればうまくできるところを、疑心暗鬼になって、無駄なジョブが投入されているのが現場で起こっている混乱である。
【小柳主査】 スケジューリングは重要な技術であり、私も心配しているところではあるが、このワーキンググループの話題ではないので、しかるべき場所でやりたいと思う。今日の議論を整理した上で、次回は項目5の残りを議論したいと思う。
林計算科学技術推進室長より、参考資料3、参考資料4に基づき説明。
村松計算科学技術推進室長補佐より、次回の日程（12月6日木曜日、17時から19時）を報告。
小柳主査より閉会発言
電話番号：03-6734-4275
メールアドレス：hpci-con@mext.go.jp