平成25年6月3日（月曜日）17時～19時
文部科学省 3階 3F1特別会議室
小柳主査，秋山委員，天野委員，石川委員※，宇川委員，加藤委員，金田委員，喜連川委員，小林委員，関口（和）委員，善甫委員，常行委員，富田委員※，中島委員，中村委員，平尾委員※，牧野委員※，松尾委員，松岡委員，村上委員，渡邉委員 ※理化学研究所計算科学研究機構側説明者として出席 （HPCI計画推進委員会）土居主査 （理化学研究所計算科学研究機構）米澤副機構長，井上統括役，泰地チームリーダー，佐藤チームリーダー
田中総括審議官，吉田研究振興局長，菱山審議官，下間情報課長，林計算科学技術推進室長，村松計算科学技術推進室長補佐
林計算科学技術推進室長より情報の取扱い等について説明。ワーキンググループの運営要領の改正が了承された。
【小柳主査】 本日は非公開の議事になるので，ただいま了承されたとおり，議論の内容については取扱いに注意いただきたい。なお，次回のこのワーキンググループは親委員会のHPCI計画推進委員会との合同会議になるが，そのときには本日の議事の内容についてHPCI計画推進委員会に報告し，公開していくことになると思う。
中間報告案では，フラッグシップシステムの開発はまず開発主体候補においてイメージを明らかにし，具体的な方向性について検討を行うことになっている。これについて，4月のワーキンググループで宇川委員から発言があった意見等を踏まえ，理化学研究所にシステムの具体案を検討していただくことになっているので，それを基に議論したい。
今回のヒアリングの視点について，まずは事務局から説明をお願いしたい。
ヒアリングの視点について，林計算科学技術推進室長より説明。また，理研が検討しているシステムの案を平尾委員より説明。質疑応答は以下のとおり。
【中島委員】 非常にアバウトな質問になるが，AICSでは「京」をターゲットに多くのスタッフが研究を進めていると思うが，ポスト「京」をやるためにはAICSの総力を挙げてポスト「京」にシフトしていかなければならなくなると思う。その辺りはどうなのか。
【平尾委員】 機構の研究チームのミッションは「京」の高度化や基盤研究であるが，この部分は「京」が動き出して少しずつ小さくなってくるので，むしろ次に向けて活動しないといけない。そのときには総力を挙げてポスト「京」の基盤研究やポスト「京」をきちっと使えるような形での研究にシフトしていくと思っている。
ただ，機構は共用補助金という形で運用されており，その枠組みでは実際のアプリケーションをやることはできないことになっている。例えば計算科学にはいろいろな分野の人がいて，実際のサイエンスをやりたい人もたくさんいるが，それが十分力を発揮できない状況にある。やはりサイエンスありきで，それを実現するためにどういうシステムを作るかということが出てくるので，サイエンスのところはほかに任せるとなると，いろいろな意味でおかしいのではないかということを主張してきた。実際のところ，いろいろな制度的な問題があることはわかるが，ポスト「京」のときにはそのような問題も考えていただきたいと思っている。現在機構にいる人たちは，このようなプロジェクトが立ち上がるのであれば，総力を挙げてその方向にシフトしていきたいと考えている。
【加藤委員】 ストレージについては「京」でも苦労していると思うが，その辺はどう考えているのか。計算した結果をどこにどう持っていって，どのようなプラットホームで可視化なり後処理をするのか。
また，計算機の性能は3年くらいで10倍になり，10年たてば1,000倍になっている。そのときにユーザが一番期待するのはコストダウンであり2012年に「京」の10ペタフロップスが，2018年には5億円くらいになるとすると，それと開発するシステムの関係はどうなるのか。つまり，その頃市場に出回っているものと全く違うアーキテクチャになると，アプリの開発部隊は二つ開発しなければならないことになるので，その辺はどう考えているのかを知りたい。
【平尾委員】 私よりも専門的な人が答えた方がいいのかもしれないが，「京」は非常に安定して稼働しており優れたところが多くあるが，一番の問題はストレージだと思う。これは単にマシンの問題ではなく，むしろソフトウェアの問題だと思っている。どのようにデータを扱うかについてはまだ改善の余地があると考えており，ポスト「京」ではそのようなところにも力を入れてやりたい。
【加藤委員】 ハード的なスペックもあるが，そもそもその時代にこのような大きなデータ，必ずしもビッグデータという意味ではなく，数十ペタバイトという非常に大きなデータが吐き出されるわけで，誰がどのプラットホームでどのように処理するかという具体的なイメージがないと，ストレージの設計ができないと思う。
【石川委員】 ストレージやファイルI/Oに関しては，東大のFSの中でも非常に重要だと思っており，アプリケーションユーザに対するヒアリングも進めている。ユースケースを決めて，その中でどうやっていくべきかを議論したいと考えている。特にアプリケーションによっては，ファイルI/O部分を書き直した方が性能が出るような場合もあるので，そういったものも含めて精査したいと思っている。
ビッグデータ関係では，理研の三好さんが気象データの話をしている。それも大きなアプリケーションの一つだと思っており，リアルタイム的な部分も含めてデータの移動を考えたいと思っている。
【佐藤チームリーダー】 2番目のコストについては，まだメーカも決まっていないので現時点では何とも言えないが，「京」のアプリの移植性も重視しており，その意味では汎用メニーコアの部分についてはそれほどかけ離れたものにはならないと思っている。
【加藤委員】 もう少し具体的に言うと，七掛けとか六掛けといったように多少の実行性能比が落ちたとしても，例えば2018年ころには10ペタが少なくとも10億はいかないくらいで使えるようになるようなことを想定して，今回の開発があるのか。
【佐藤チームリーダー】 コストについてはまだ検討中なので回答は控えさせていただきたい。ソフトウェアについては加速機構の部分で懸念があると思うが，なるべく既存のプログラムをディレクティブベースで書き換えて，ユーザの負担にならないように検討したいと考えている。
【小柳主査】 加藤委員の質問のポイントは，その時点で普及しているサーバと，この最先端システムの間のシームレスはどう実現するかということだと思う。
【加藤委員】 エクサだけがある世界ではなく，10ペタがもっと普及しているという全体像がないと，分野としては進まないのではないか。
【秋山委員】 演算加速機構について，この方向に向かうことは十分アプリケーション屋としても理解していて期待もしているが，新しい速いマシンを作るときに，安定しない非常に速いシステムよりも，多少オリジナリティがなかったり，余り速くなくても安定したシステムでないとアプリケーション屋は困る。はじめからフォールトトレラントにデザインされていて，1枚や2枚おかしいものがあってもそこに戻れる仕組みまで考えていただけるならいいが，そうでないと日常的な加速機としては使えない。信頼性についてどういった議論がされてきたのかを聞きたい。
【佐藤チームリーダー】 信頼性については計算科学研究機構が企業とともに開発するようにしており，これまでプロセッサ開発に実績のある企業に入っていただき，RAS機能などについては日本メーカの技術を使って信頼性を高める。その上で，例えばチェックポインティングについては，この規模になるので計算科学研究機構でも研究としてやらなければならないと考えている。
【秋山委員】 例えばNVIDIAといったところが作るボードと，1枚当たりの信頼性については遜色のないものを目指しているという理解でよろしいか。
【牧野委員】 遜色のないレベルでは使い物にならないので，それより桁が高いレベルの信頼性がないといけないと思っている。
【秋山委員】 そのためには何をするのか，という議論がどのくらいあるのか。
【牧野委員】 基本的に現在のNVIDIAなどの場合には，演算器レベルのRASは入っていないという理解であるが，これからは演算器レベル，つまりプロセッサの全部の要素にエラー訂正機能を付けざるを得ないと思っている。これは結構なオーバーヘッドになるが，やむを得ないであろうということで検討を進めている。
【佐藤チームリーダー】 その辺については企業のノウハウも生かして一緒に開発するという形で，信頼性のあるハードウェアを開発したいと考えている。
【井上統括役】 日本の企業の強みは，メインフレーム時代からやってきたということがある。現時点では具体的にどのベンダに何をやらせるかまでは特定していないため，どこの会社の技術をどう使うかは答えられない。いずれにせよ日本で持っている大きな強みではあるので，それを生かして進めていきたいと考えている。
【善甫委員】 基本的な考え方のところで，中間報告ではグランドデザインとして一つのトップレベルのスーパーコンピュータと，それを支える幾つかのシステムというような基本的な考え方を議論したと思う。今回報告いただいたものは，複合機のように考えられるが，汎用的に使えるものをまず作って，特別な分野はまた別の，それを支えるような領域を持ってくるものだと理解している。それと今回のものは基本的な考え方として合致しているのか。
【平尾委員】 私たちは，日本の計算機資源のピラミッド構造のトップに位置するフラッグシップマシン，これの開発はどうあるべきかという観点で議論してきた。私の報告も，これで全ての分野をカバーできているわけではなく，ユーザの要求によっては少し欠けているところもある。その部分に関しては，それを補完するシステムを国が別に用意することを考えていただきたいと思っている。私たちは汎用機と加速機が一体となったものとしてフラッグシップマシンを提案している。
【善甫委員】 全体をカバーするというのは，グランドデザインに書いてある，ある程度の領域をカバーするトップレベルのマシンがあって，カバーできないところはそれを支える幾つかのマシンがあるというように理解していたが，そうではないのか。
【小柳主査】 つまり，理研が提案しているシステムがどの部分に当たるかということになる。中間報告では，リーディングマシンとしては複数のシステムを考えているが，その中にフラッグシップという一つのシステムがあると書いている。
【中村委員】 メモリ容量とメモリ帯域の図は富田先生の方でいろいろなアプリを調べて作成したと思うが，リーディングマシンが複数であるとすると，ここの全ての点をカバーしているのはおかしいはずである。むしろフラッグシップはここだというのがあって，それから外れる部分は今のフラッグシップの提案ではカバーできないから，それは別のアーキテクチャのリーディングマシンに任せたいということであれば理解できるが，全てをカバーし過ぎているような印象がある。
【富田委員】 数値的にはまだ精査中のところがあるが，全部がカバーできるとは思っていない。ただ，大概のものはカバーできるようなものがフラッグシップとしてふさわしいと解釈している。
【井上統括役】 あたかも二つのマシンが切れて2種類あるように見えるが，物理的な実装イメージはこれから詰めていく段階だと思っている。できるだけ広いカバレッジを持ったものがフラッグシップであるという観点で検討しているが，その中で，システムソフトウェアも含めて一体のマシンとして動かし，それぞれの役割分担をそれぞれのチップが担っていくような形で検討した結果である。
【中島委員】 議論がかみ合わないのは，パフォーマンス以外の要素がまだはっきりしていないということがあると思う。カバーしようと思えば，ある意味で幾らでもカバーはできるので，この幅をどのくらいまで広げていくかになる。開発に対するリスクやパフォーマンスといった観点で，まだ精査し切れていないと思う。運用面でも開発面でも安くできるならカバーしてもらった方がいいわけで，オペレーションコストなりを発生しないように今後も精査を続けてくださいと言うしかないと思う。
【井上統括役】 まさに中島先生のおっしゃるとおりで，電力とコストの両面を考えたときに，例えば一つの案としては全部汎用メニーコアでカバーするというやり方もあるし，一方で，全部加速機構でカバーして，それに汎用部を付けていくという考え方もあると思う。しかしながら，このような極端な形をとると，電力，コストも考えたときには難しいというのが基本的な考えになる。電力当たりの性能やコスト当たり性能を考えたときには，このような複合型，要するにチップとして2種類のものをシステムソフトウェアで統合し，一つのシステムとして見せていくというイメージになっている。
【小柳主査】 何でもカバーするということを強調し過ぎているような印象があるので，誤解を生んでいるのではないかと思う。飽くまで汎用的であって，なるべく広くはするけれども，いろいろな資源の問題との兼ね合いでトレードオフになると思う。
【常行委員】 CPUの数が増えて加速機構が付くと，平尾先生がおっしゃったように数値計算ライブラリの役割が非常に重要になると思う。数値計算ライブラリについてはどこが担当して，どの段階でアプリケーションの開発者が使えるようになるのかを教えてほしい。
また，「京」コンピュータのソフトウェアの移行に関して，それがしやすいシステムということが書かれているが，これは具体的に言うと何をするのか。例えばミドルウェアのレベルでシステムの違いを吸収できるようなものを考えているのか，そのあたりも教えていただきたい。
【平尾委員】 数値計算ライブラリについては，機構が主体的に中心になって，全国の研究者と一緒に開発したいと思っている。機構では既に今村チームリーダーが数値計算ライブラリの開発をやっているが，そのような人たちを中心として開発を行う。工程表には新規－計算科学推進プロジェクトがあるが，2014年度からスタートし，準備をしていきたいと思っている。
【佐藤チームリーダー】 数値計算ライブラリについては，加速機構や通信ネットワーク，あるいはプロセッサのSIMD演算に依存するところは独自開発が必要だと思う。全体のアルゴリズムについては，国際協力しながら標準的なライブラリにすることがもう一つのアジェンダとして挙げられる。
【石川委員】 後半の質問はシステムソフトウェア関係だと思うが，メニーコアの計算ノードの中で基本はマイクロカーネルが動き，Linuxカーネルが動く部分も数コア存在する。「京」のときとは違いフルセットのLinuxがそこで動くことになる。マイクロカーネルの方からLinuxのAPIはそちら側にデリゲーションして動かすという機構を開発し評価を始めている。現在はMICを使っているが，今後富士通の上でも確認していくことを考えている。「京」のように選択的なツールしか計算ノードで動かないのではなく，基本Linuxで動くものは動くという方向で考えているので，ユーザから見るとコモディティのクラスタからのシームレスな環境を提供できることになる。ただし，全てのツールについて最適化できるとは思えないので，ツールの最適化についてはプライオリティが付くことになる。
【金田委員】 今の質問にあったように，シームレスというのを具体的にどうするかが，ユーザとしては一番気掛かりなところなので，そこを整理していただくのが重要だと思う。
【村上委員】 一つ前の議論に戻るかもしれないが，全ての開発の工数，労力は，アーキテクチャをどうするかに結構依存してきている。消費電力性能効率を考えると，アクセラレータはある意味自然な流れなのかもしれないが，ただ，アクセラレータありきのようにも見えるところがある。アクセラレータ・プラス・メニーコアで全てをカバーするというよりも，メニーコアだけでもカバーできるように見える。先ほど井上さんが，いろいろな選択肢がありまだ何も排除していないということをおっしゃったが，要はコストという観点で，ソフトウェアの開発コストや，コモディティのマシンとのシームレスさをどう担保するといったいろいろなコストがある中で，消費電力は確かに重要なコストではあるが，アクセラレータを入れることによって新たに発生するコストも含め，全体で考える必要があると思う。
【井上統括役】 まさに御指摘のとおりだと思う。確かに汎用メニーコアでカバーする部分は多いが，基本的にはそれぞれの得意分野が特定されてくると思っており，その中で，両者をうまく融合させて使っていくことになる。逆に言えば，あるアプリケーションを動かすのに，それを無理やり両方が同時に動いていなければいけないという制約をはめたら，これは本末転倒になると思っている。現実的にはそれぞれの得意分野のところに割り当ててチップを動かしていくことを，システムソフトウェアとの連携でなし遂げていくという課題になると思っている。
【佐藤チームリーダー】 汎用メニーコアでもカバーできるが，現時点ではコストイコール電力という観点から，加速機構の方がコストが低い。もちろん，御指摘のようにいろいろなものを含めてという話になるが，それについては現在精査中なので，それを見て判断していただきたいと思う。
【秋山委員】 今回の計画は「京」のときに増していい計画だと思うが，今日の話を聞いていると，システムソフトウェアやストレージも含めて，結局全部やることになっている。「京」のときはVenusやTofuの開発にお金が必要だったと思うが，今回はどこを削ることによってこれだけ多くのことができるのか。
【井上統括役】 「京」のときはこれまでの日本の伝統技術を最大限つぎ込む形でプロセッサを作り，そしてシステムは大規模超並列マシンという概念を作ってきた。ここで作られたものは，当然ながら次に継承されていくと思っている。加速機構というとメカニズムが全く違うようなイメージに見えるかもしれないが，要するにチップの中に小さなコアとメモリが入り，そこには「京」でも実現してきたRASの機能を入れていく。そのような技術的な継承が非常に大きな部分になると思う。もちろん，汎用のメニーコアの方もいろいろ強化する部分はあるが，そこも技術を継承してやっていく。半導体のファブについては，これから新たに日本でやるのではなく，汎用に世界で使われているものの中で，いいものに乗っていくという選択肢をとるべきだと考えているし，その方向で検討している。
【石川委員】 加速機の部分は理研が設計を行うもので，決して企業側というわけではない。また，システムソフトウェアも理研が中心となり，企業も一緒にやっていくことにはなるが，だからといって独自仕様にならないように国際協力を考えている。
結局のところ，開発予算に関しては人件費がかさむと思うが，その意味でオールジャパン体制と書いたのは，皆さんに是非御協力いただきたいということを言いたい。そういうものがないと，予算面でうまくいかなくなるのではないかと思っている。
【松岡委員】 プロジェクトとして，海外の競合に対してどう勝てるかが気になる。ここでは汎用メニーコア，マルチコア，メニーコアと加速機構を別々に開発するように見えるが，今の世の中の流れとしてはそれを一体型で開発する方向にある。NVIDIAもエシュロンもARMコアをインテグレーションし，かつ，ネットワークもインテグレーションする。インテルやAMDなどもその方向で，メモリ空間を共有した上で，へテロジニアスだけれども汎用的なコンピューティングの統合アーキテクチャを作るという流れになっている。そのあたりどうなのか。
もう一つは，技術的にどこで勝てるのかというところで，例えばメニーコアのRASというのは大変難しく，今のGPUはECCプロテクションが全部入っているが，それ以上のECCは「京」を見ても分かるように非常にアーキテクチャステートを大きくとっておかなければならなくなる。そのようなことも含めて，技術的に本当に勝てるのはどういうところなのかを教えていただきたい。
【井上統括役】 チップ構成としては確かにアクセラレータ部分と汎用部分が分かれて作るとしても，メモリ空間を共有していくのは世界の流れに反しているものではなく，そこは何らかの形で実現していきたいと思っている。ただ，ここは実装イメージと密接に関わるところだと思っており，実装としては多次元実装等の形が出てきている。その中で，一つのチップの中に両方入れるのが得なのか，あるいはチップとしてはそれぞれプロセスも含めて特化した形で入れたものを実装の中で一つにしていくのか，そのレベルもいろいろあると思っており，そこはこれから詳細を詰めていく中で進めていきたいと思っている。メモリ空間が全然別なものになっているのは決して望ましい姿ではないという点は，松岡先生のおっしゃるとおりだと思う。
【佐藤チームリーダー】 井上さんの話と矛盾するところがあるかもしれないが，現実の可能性として，いろいろなものをインテグレーションしたチップを新規に開発できるのかを考えたときに，それはかなり難しいだろうと思っている。加速機構でどのようなものをカバーできるか，あるいは汎用の方でどのようなものがカバーできるかについては，富田さんあるいは加速機構の方にも参加していただいている牧野さんと一緒に考えて，全体としてアプリケーションが世界最高性能で動くようなアーキテクチャを目指していきたいと思う。逆に言えば，メモリがインテグレーションされていることがもちろん望ましいとは思うが，それでなくても両方のメリットが生かせるようなアプリケーションの構成を検討していくことが求められていると考えている。
【牧野委員】 加速機構を設計する側からいうと，一体にすると開発サイクルが長くなるので，実際にそのアプローチが5年後，10年後に本当にその方向に行くのかどうかは，今のところまだ疑わしいと思っている。分離することで設計コストを下げることと，今回のシステムの場合は分離することで演算加速機側にコンパクトなネットワークをつけることができるようになっていて，この部分はほかの一体型のアプローチにはないアドバンテージになると考えている。
【松岡委員】 ネットワークが付くのがアドバンテージになるということか。
【牧野委員】 演算加速機構側に，そのオペレーションモードに特化したネットワークを付けるということである。
【松岡委員】 ほかのいろいろなCPUも2016年くらいからその統合ネットワークをやるが，それより圧倒的に速いものが付くということか。
【牧野委員】 速くできるように作らないと，作る意味はないと思う。
【中村委員】 別の観点の質問になるが，工程表では2019年から20年に設置・調整があるが，ここは「京」の能力をある程度維持したままでどのように変更していくのか，そのイメージがあればお伺いしたい。
【平尾委員】 2019年のところの設置・調整は，「京」のリプレースのような感じを考えているので，ここでは「京」は停止することになる。
【中村委員】 フィージビリティーは三つのグループが独立にやっているので，その結果としては三つくらいのリーディングマシンのイメージがあり，その一つがフラッグシップになるというイメージがあった。この検討はオールジャパンでやらないと難しいというのもよく分かるが，そうするとフラッグシップマシン以外のリーディングマシンは作るのが難しくなるということなのか。あるいは逆に，フラッグシップ以外のリーディングマシンも含めて，ポスト「京」プロジェクトの検討体制で考えることになるのか。
【米澤副機構長】 ポスト「京」の我々の提案を補完するいわゆるセカンドレベルのマシンは，文科省の予算で作っていただけると思っている。
【林計算科学技術推進室長】 予算の話ではなく，国を挙げてこれを開発すると，ほかを開発するパワーがないのではないかという質問だと思うが。
【米澤副機構長】 ここにいる人々のみならず，もっと日本全国に人材はいると認識しおり，それは三つのFSの中でカバーされている方々も含め，十分ほかにやっていけると思っている。
【加藤委員】 この後はどうなるのか。つまり，演算性能を確保しようとすると，今の20倍くらいまでのメモリが限界だというスペックであるが，それを前提にしなければいけないのか，それとも汎用チップはまだ伸びる可能性があるのか。その辺の情報がある程度ないと，アプリの開発者はどちらに行けばいいかという判断ができない。
例えば，汎用では300までしか行かないとなったときに，汎用のその後はどうなるのか。加速機は確かに重要だと思うが，それでカバーできる分野はごく限られており，やはりマーケットのボリュームは汎用機にあると思う。そのときに汎用機がどうなっていくのかというビジョンを知りたい。
【牧野委員】 非常に大ざっぱなことを言うと，汎用機にしても専用にしても一つのチップに載るメモリは大きくなるし，それに対して外のメモリへのバンド幅が上がらないという傾向は避けられないと思う。たくさんメモリを使いたいならばB/F値は落ちる，若しくは今よりも上がらない方向で考えざるを得ないと思う。
【加藤委員】 この計画ではメモリ比を相対的に「京」の5分の1か6分の1に汎用そのものも落としていますよね。
【牧野委員】 それはいろいろ調べた結果，「京」からスケールするほどの大きなメモリを要求しているアプリケーションが余りなかったので，そうなっている。
【加藤委員】 汎用はまだ伸びるというメッセージなのか，もう限界なのかというのは，どこかの段階ではっきりしていただいた方がアプリの開発側としては有り難い。
【牧野委員】 それに関して言えることは，オンチップでアベイラブルなメモリ量は増えるので，そこでアプリケーションが入るのかをまずは考えてもらうことになると思う。
【佐藤チームリーダー】 B/F値についてはまだ検討中なので，資料には書いていない。
【松岡委員】 加速機のマーケットはとても大きく，今後エンベデッドの世界では，スマホが10億台に達すると言われていて，それには全てGPUが入る。世の中がスマホ化すると，インテリジェントな普通のCPU，汎用CPU，GPUのコンビネーションというのは年間20億個くらいになるので，3億個くらいのPCに比べても巨大なマーケットになる。HPCに使えるかどうかは別として，それが全部プログラマブルになるとOpenCLなどを使うようになり，ソフトウェアのインフラとしてはそのぐらいの汎用性がある。「京」のいいところは，いろいろな意味で汎用アーキテクチャとも連続性があることで，例えばPCクラスタだとクレイで動いているものが「京」でも結構そのまま動く。コンパイラの差異はあるので，それで皆さんが苦労しているのは知っているが，おしなべて言うとLinuxは動いて，Lustreは動いて，MPIは動いてということで大体動いている。「京」が成功した一つの大きな理由はそこにあると思う。今後20億個の，いわばGPUという形でのベクトル加速機のマーケットをどうやってレバレッジするのか。
【佐藤チームリーダー】 どの点を見てGPUのマーケットと言うか，その定義にもよると思うが，いわゆるデータパラレルという形の形態であれば加速機でもサポートできると考えている。
【松岡委員】 つまり，OpenCLやOpenACCといったソフトウェアがこの加速機で実現されるということか。
【佐藤チームリーダー】 データパラレルという意味ではということになる。いろいろなメモリをランダムアクセスできるようにするかについてはFSの中でも検討するし，あるいは，これが正式にローンチしたときに最終的にどういうアーキテクチャになるかは，もしそういうデマンドが大きいのであれば，松岡先生が御指摘のように既存のGPUで実行されるソフトウェアをそのままの形で実行できるような形を追求しなくてはいけないと思っている。
【喜連川委員】 大学のインボルブメントが今回の「京」の場合にどのくらいなされたのか，「京」のアーキテクチャを見たときに大学の知がそこに入っているのか，そのようなオポチュニティが十分あったのかというところで，先ほどはCo-designというすばらしい言葉を頂いたと思う。今後の日本の研究開発体制を考えるときに，若い研究者がしっかりと組み込まれたような体制がないと，ベンダにとっても次の人材がなかなか育ってこないと思う。とりわけ，ソフトとアーキテクチャとアプリがあるが，加藤先生から質問があったようなことは，デバイスの専門家がいないと答えられない話になる。そういう人たちもチームに入れ，デバイスは究極どこまで行けるのかという感覚みたいなものも入れて，大学とのタイトな開発体制をどのように検討されているのかをお伺いしたい。
【平尾委員】 「京」のときはどうだったのかということから，ある種の反省をしないといけないと思っている。「京」の開発は大学や日本の持っている知を全て結集してやったかというと，必ずしも十分ではなかったのではないかと，私は周りから見ていて感じている。日本の大学や研究所も含めた知の結集が，今回のプロジェクトを成功に導くにためには必須だと思っている。同時に，Co-designといったように計算機科学と計算科学の人が一緒になってやらないといけない。幸いにも神戸の機構には，既に核になる人たちがいるので，その人たちを中心として，大学の方々などを結集してこのプロジェクトを進めたいと思っている。
デバイスについても大体はそろっていると思うが，確かに本当の意味のデバイスのところはいないかもしれない。大学にはいろいろな方がいるので，現在のチームとして欠けている部分は補っていくべきだと思っている。オールジャパンでやりたいと思っているので，御協力いただきたい。
【喜連川委員】 デバイスの研究開発も随分されてはいるが，いまひとつリターンが上がっていないのが現状だと思う。このようなところで是非活躍していただければ有り難い。
現状のビッグデータは感覚的に言うとコンピュートインテンシブとデータインテンシブの双対構造から見ると，CPUを使わない構造になっており，HadoopでもCPU利用率を平均すると大体半分くらいというのが普通である。説明いただいたアーキテクチャの図の中で，どこがビッグデータに対応しているのかを教えていただきたい。
【石川委員】 アーキテクチャ的に見れば，いかにデータをCPU側に供給するかという話になる。例えば，ジョブ間では今はファイル渡しにしていたりするが，それぞれのジョブが同時に動作しているならば，パイプライン処理ができるような仕組みを作っていくとか，システムソフトウェア的なところでビッグデータに対応することが必要だと思っている。MapReduce系の場合でも，理研の計算科学研究機構で「京」向けのMapReduceを作っているし，システムソフトウェアとしてビッグデータとスパコンをどう捉えるかという観点で考えなければいけないと思う。
理研で既に始まっているのは，播磨のXFELから出てくるデータを「京」でオンライン処理して実験施設にフィードバックするといった話もあり，インターネット経由でいかにデータをリアルタイムに受け渡し，「京」のようなマシンにジョブを投入していくかといったところも含めて考えなければいけないと思う。
【小柳主査】 まだ議論は十分かみ合っていない部分もあると思うが，それは委員からの重要な指摘として受け止めさせていただきたい。
本日はいろいろ議論を頂いたが，まず第一に，理化学研究所が開発主体の候補として適切であるということをここで確認いただきたいと思う。そのような前提で，今後さらなる具体化について理化学研究所に検討していただくということでよろしいか。
（「異議なし」）
【小柳主査】 それでは，そういうことで今後進めさせていただきたい。
システムの検討についてはより細かい議論も必要になるので，本ワーキンググループの下に10人程度のサブワーキンググループを設置して，引き続き議論をしていきたいと思う。メンバーについてはこのワーキンググループのメンバーを中心に構成し，外部の専門家も追加したいと思っている。人選については，主査である私に御一任いただきたいがよろしいか。また，サブワーキンググループの主査も私になるが，これも了解いただきたいと思う。
（「異議なし」）
【小柳主査】 ありがとうございます。
この議題は以上になるが，最初に申し上げたように本日は非公開であり，議論の内容については秘密情報に触れない程度に事務で取りまとめ，次回のワーキンググループとHPCI計画推進委員会の合同会議で報告させていただく。ここでの議論については取扱いに留意いただきたい。
村松計算科学技術推進室長補佐より，次回の日程（6月25日）及びHPCI計画推進委員会との合同会議でとなる旨を報告。
小柳主査より閉会発言
電話番号：03-6734-4275
メールアドレス：hpci-con@mext.go.jp