ここからサイトの主なメニューです

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

1.日時

平成25年3月27日(水曜日)16時~19時

2.場所

文部科学省 5階 5F3会議室

3.出席者

委員

小柳主査,青木委員,秋山委員,天野委員,石川委員,宇川委員,加藤委員,小林委員,関口(智)委員,善甫委員,高田委員,富田委員,中島委員,中村委員,平尾委員,牧野委員,松尾委員,松岡委員,村上委員,室井委員,渡邉委員
(HPCI計画推進委員会)土居主査
(筑波大学)佐藤センター長
(富士通株式会社)堀越シニアプロフェッショナル,追永本部長,新庄本部長代理

文部科学省

下間情報課長,林計算科学技術推進室長,村松計算科学技術推進室長補佐

4.議事録

(1)「将来のHPCIシステムのあり方の調査研究」のシステム設計研究に関するヒアリング

資料1-1に基づき小林委員より説明。質疑応答は以下のとおり。

【宇川委員】  11ページの性能推定結果について,実効性能を何%,何FLOPSといういい方だとどのくらいになるのか。
【小林委員】  ノードレベルで最大50%から30%くらいまで幅がある。
【宇川委員】  例えばRSGDXを見ると230エクサFLOPSなので,100ペタFLOPSで走れば2,300秒で計算できるところが,9時間なので10%を切ることになる。メモリバンド幅を保証して実効性能を上げようというアーキテクチャだと思うので,この表はそのような数値も出していただいた方がいいと思う。
【小林委員】  分かりました。効率についても評価は進めてはいるが,今は数値を紹介できない。
【室井委員】  性能の推定のところで,I/Oはどうしているのか。
【小林委員】  今はデータがないが,データ同化のアプリケーションでI/Oの評価を進めていて,メモリサイズの5倍くらいだったと思う。
【牧野委員】  電力とメモリバンド幅を余りいじらないで演算速度を上げる余地があるような提案になっているが,B/Fを保つために演算のところを下げているようにも見える。それに対して,より演算速度を上げた方が計算機としての汎用性は高まるように思うが,その辺はどうお考えか。
【小林委員】  その使われないFLOPSのバジェットをメモリ性能にうまくバランスして持っていくというのが基本的な考え方です。
【牧野委員】  メモリバンド幅が必要ではないアプリケーションのことは考えないということなのか。
【小林委員】  メモリが必要ないアプリケーションはピーク性能が上限になってしまうかもしれないが,そこは適材適所で,アクセラレータで解決していただけると思っている。
【中島委員】  4GF/Wとか2.5GF/Wあたりを狙っているということで,メモリバンド幅を稼ぐためにどのくらいの電気が必要になるのか。
【小林委員】  見積りはあるが開示できない。
【富田委員】  アプリケーション側の立場から申し上げると,社会的課題の設定について,防災のところは明確に提示していただいているが,そのほかのところ,例えば気象,あるいは,ものづくりはどのようにスペックが決まっているのか。MSSGの例では,これだけだと何をやるのかが分からない。
【小林委員】  MSSGについては,100メートルメッシュの精度で3日間の気象予測を,6時間以内に計算したいということで要求が来ている。
【富田委員】  100メートルメッシュでやったときに,今までとどう違ったものが見えてくるのかという議論が必要だと思う。
【小林委員】  都市スケールのシミュレーションということで,建物間での流れなどが分析できるというように聞いている。あとは,より狭い領域でのゲリラ豪雨の予測などが可能になると聞いている。
【富田委員】  その部分を,例えば学会などでもう少し議論してもらう,あるいは,FSで実際にそれに乗っかっていただいて課題設定をしていく方が望ましいと思う。
【小林委員】  既に富田先生のグループと連携するということを基本でやっている。
【富田委員】  防災のところは非常にコントリビューションしていただいて助かっている。
【小柳主査】  後で全体のディスカッションもあるので,質疑はここまでとし,引き続いて石川委員からお願いします。

資料1-2に基づき石川委員より説明。質疑応答は以下のとおり。

【青木委員】  全体B/Fの概念がよく分からない。アプリケーション実行時のメモリバンド幅をアプリケーション実行時のFLOPSで割るというのは,性能が悪いほど値が大きくなるということなのか。
【石川委員】  アプリ側で言っているのはこのような計算のB/Fになる。例えばこのループにおいての実行は25.6ギガFLOPS出たとすると,そのときに,メモリはどれだけスループットがあったかというところから,この値をだしている。
【小柳主査】  B/F値もいろいろな定義があり,例えばキャッシュの効果をどこまで見るかにもよるので,ここで議論するのではなくFSのチームで議論してほしい。
【宇川委員】  B/Fはある計算をするためにどれだけの演算が必要かを求め,それを計算するために必要なメモリとCPUの間のロード・ストアの数で割ることになる。それに対して,実際のハードウェアやプログラムがどこまでいけるのかが問題であって,これは測定値になる。
【牧野委員】  石川さんが考えている方が,今のハードウェアに対する測定値としては適切になる。つまり,キャッシュの効果を織り込んでいることになる。理論的なB/Fと比較するときも,当然キャッシュをどれだけ使ったかを含めて評価しているので,その意味での測定値になっているとは思うが,本来必要なB/Fが幾らかということに対する答えにはなってない。その意味では,キャッシュが理想的に働いたときのB/Fが理論値であって,それはロード・ストアの回数とは違うことになる。アプリのグループでは,これを使うことになるはずである。
【松岡委員】  FSでやるのもそれです。
【石川委員】  重要なのは,それぞれのグループが言っているB/Fの計算式が何かというのをしっかりしておかなければいけないと思う。
【牧野委員】  想定しているマシンのB/Fの値はどれくらいなのか。
【富士通(新庄)】  100PB/sくらいを狙いたい。
【石川委員】  台数を増やすことによって総メモリ容量を増やすので,100PB/sというと300の方に振られたときの話ということになる。
【松岡委員】  メモリテクノロジ及びインタフェースのテクノロジはどのようなものを使う予定なのか。
【富士通(新庄)】  HMCをベースとしてメモリを構成しようと考えている。
【松岡委員】  何チャンネルで,何レイヤくらいの積層を考えているのか。
【富士通(新庄)】  HMC8チャンネルを1ノードに接続することを考えている。チャンネルの幅についてはバリエーションが可能になると考えている。また,レイヤ数についてはHMCのベンダと話をしているが,これはベンダとの機密情報である。
【加藤委員】  ネットワーク性能はどれくらいになるのか。例えばB/F2であれば,ネットワークで例えば0.2とか,それがアプリにとっては重要になる。
【石川委員】  ネットワークはTofuの延長,あるいはDragonflyみたいなものを考えている。ネットワークや並列性能を含めての評価はやっと始まったところで,まだ詰めているわけではない。
【小柳主査】  次は筑波大学の佐藤センター長からお願いします。

資料1-3に基づき佐藤センター長より説明。質疑応答は以下のとおり。

【中島委員】  2,000チップくらいのグループで,そのグループがたくさんあるような構成になると思うが,たくさんのグループをそれなりにコミュニケートして使うようなアプリケーションは余り相手にしないということなのか。
【佐藤センター長】  例えば,本当にいいケースでうまい階層的な構造が持てるのであれば,グループごとにやって,その下の階層を汎用で行うということが考えられるが,かなり難しい話だと思う。例えば気象の問題では,カップラという形でその連成のコンポーネントを結んでいるが,そのコンポーネントの一つを演算加速機構でやり,ほかのコンポーネントは汎用のところで実行する。それで,カップラを通じてコミュニケーションするというようなイメージもある。
【中島委員】  グループの中ではすごくケーパビリティコンピューテングに走っていて,システム全体ではそのケーパビリティコンピューテングの和のキャパシティコンピューテングを目指すようになるということか。
【牧野委員】  補足すると,我々は二兎を追うようなものになっていて,アーキテクチャの4タイプでいうメモリ削減型と計算重視型の両方になる。メモリ削減型では割合小さな単位に関しては密結合したようなものを考え,計算重視型では必ずしもそういう密結合したネットワークを必要としない,GPUカスタムのような使い方を想定するので,そのときは割合大きな計算までを想定することになる。
【中島委員】  オンチップに載るかどうかという話では,例えば石川さんの所では,5B/Fとか10B/Fと言っているが,それを無理やりキャッシュに当て込むことによって,見掛け上の実効のB/Fを出すというような話をしているが,その検討はしているのか。つまり,外付けにバンド幅が低いメモリがあって,それとオンチップのメモリを一種のキャッシュのように使って回すと性能が出るという話は常にある。その辺の検討はこのアプリケーションの中ではしていないのか。
【佐藤センター長】  これは私の考えですが,1つは現在のテクノロジ,つまり65ナノや45ナノだとオンチップのメモリが小さいが,10ナノになってある程度容量が増えてくると,この上で計算できるアプリケーションもある程度はあるのではないかというのが1点。もう1点は外付けのメモリについて,キャッシュという形でそのオンデマンドにやるのはなかなか難しいと思う。
【中島委員】  キャッシュと言ったのは,キャッシュ的に使うということである。
【佐藤センター長】  我々はグローバルメモリと呼んでいるが,そこから転送命令を出して,レギュラーにスケジューリングしながらデータを入れ替えて計算するような形にすると,もちろんB/Fの話はあるが,そこそこ演算機は回せるような形になるということを期待している。
【牧野委員】  スライドの7ページにあるが,磁気流体コードの場合には実際にグローバルメモリを使った場合の演算速度を検討していて,意外によい数字になっている。格子QCDとMDに関しては,そもそも必要なデータ数が小さいので,どうしてもキャッシュに入ってしまう。地震波についてはこれから磁気流体と同様な検討をする予定です。重力多体と,来年度検討予定のものに関しては,基本的にアクセラレータとして使うというタイプなので,その意味ではメモリ量が制限になっているアプリケーションではない。
【加藤委員】  簡単に言うと,ギガバイト,ギガFLOPS値を従来の1万分の1くらいにして,今のキャッシュよりも小さくして,その代わりに演算性能を高めていると思う。それでB/Fを確保するのは分かるが,そのときにチップ内では性能が出るが,チップ間で問題は起こらないのか。チップ内がそれだけ動けば,チップ間に取りに行ったときにその遅延が問題になるような気がする。
【佐藤センター長】  50ギガbpsのテクノロジがリンクとして使えるということであれば,2次元メッシュに限定すればチップ内のネットワークをそのまま延長したのと同じようなバンド幅になる。50ギガbpsというのはインフィニバンドの次,100ギガイーサか何かに使われるテクノロジだが,プリント基板上では10センチしか飛ばないので,それを外側に飛ばしていくためには,シリコンインターポーザ上で光を使わないといけない。そこまで行くか,半分の25ギガbpsで済ませるのか。そこでギャップができることになる。
【加藤委員】  それも基本的には隣同士でしか通信しないという前提なのか。
【佐藤センター長】  そうです。
【小柳主査】  あとはリダクション演算がどのくらいになるか,減らす努力はすると思うが。
 まだ議論はあるが,ここで三つの発表の議論を終わって,FSの中間評価の結果について林室長から説明をお願いします。

資料2に基づき林計算科学技術推進室長より説明。質疑応答は以下のとおり。

【平尾委員】  この中間評価はこれまでやってきたFS研究が妥当に行われているかという評価であり,提案されたシステムに対する評価ではない。実際の提案されたシステムの評価はどこがやるのか。
【林計算科学技術推進室長】  システムの評価はこのワーキンググループでやっていくとことになる。
【小柳主査】  三つのFSのプレゼンテーションがあったが,我々としてどのような方向性を出していくかというとき,大変重要な資料である。論点整理の,計算科学技術に関する研究開発の方向性にこのような成果を含めていきたいと思う。
【高田委員】  システムの専門家ではないので的外れな質問になるかもしれないが,コンパイラやプログラミング環境のところで,佐藤先生の発表ではこれに数年掛かるという話が書いてある。石川先生と小林先生の話は,例えば地球シミュレータとか,「京」の延長というイメージがあるので,ユーザから見たときにイメージしやすいが,筑波大の場合,プログラミングする人から見たイメージは敷居が高いようなものになるのか。
【佐藤センター長】  OpenACCという最近GPUに使われるようなディレクティブベースのものに,XcalableMPというコンセプトを使えば,ある程度のものはコードジェネレーションできると思う。
【高田委員】  ユーザから見えないところで工夫はするが,ユーザ自身がそこにギャップを感じるということではないということか。
【佐藤センター長】  ええ。一番重要なところは,どこのコードをどうオフロードするかをきちっとやらないといけない。それに関してはGPUと同じような知見が必要になる。そこは今までのアプリケーションとは少しはギャップがあるが,それについてはGPUコンピューテングである程度の準備はできていると思う。
 数年掛かるというのは,そういったものが成熟していくためには数年掛かるという意味で,FSの間にある程度のこんな形で書けばこういうコードが出るというのは出していきたいと考えている。
【加藤委員】  コーディングの問題以前に,データストラクチャの問題の方が重要だと思っている。これを見ると,チップ内もチップ間もモジュール間も全てストラクチャードデータで,かつ隣接からしかデータを持ってこないという前提のアーキテクチャになっている。そうすると,汎用性という意味ではかなり苦しいという気がする。これにフィットしたものはいいが,例えばものづくり分野のコードはストラクチャードばかりではなく,また気象分野もアンストラクチャは多いと思うが,そこは基本的に使えないということなのか。
【佐藤センター長】  基本的に,全てをカバーするわけではなく,いわゆる疎行列のようなものに関しては,ある程度できないものもあり得て,そのようなものは汎用でやることになる。
【加藤委員】  先ほど,なぜ50ギガbpsで性能が出るのか不思議に思ったが,基本的にデータがこういうストラクチャをしていない限りは,チップ中の1つのコアがほんとに隣から持ってくるようなイメージでしかないということですね。全体の16テラFLOPSに対してのネットワーク性能という意味ではないということなのか。
【佐藤センター長】  そうです。
【宇川委員】  今の加藤さんの意見に対しては反論があって,次にエクサをやるというのはそれなりにブレークスルーが必要になる。今まで慣れ親しんだコードはそれでいいし,アーキテクチャもいいが,こういうことをやるためにコードの革新も必要だったらやるということは考えておかなければいけないのではないか。そこはいろいろ意見があると思う。
 先ほどの平尾先生の質問に関係するが,このワーキンググループで決めるとすると,この資料だけではざくっとし過ぎているのではないかと思う。ノードの基本的な構成やスペック,それに対してこのアプリではこのような性能が出るというような資料になっていないと,それぞれのシステムがいいか悪いか言えないと思う。
【松岡委員】  アプリFSとしてはそれもある程度平準化しようということでミニアプリをやっているが,それだけではなく,データセットも標準化しないと比べようがない。例えば先ほどの筑波大の場合,比較的小さいデータセットでは発揮するが,大きくなると性能がでない。それは仕方がないことで,そういうふうになっている。
 そのため,平準化したアプリケーションとそれに対するデータセット,要するにインプットパラメータを標準化して比較する必要がある。単純にアプリケーションだけの統一だと平準化されない。
【平尾委員】  このプロジェクトはリーディングマシン,世界最先端のシステムを作ることが目標なので,もちろんこれをやり遂げないといけないのは分かるが,何となくコンサバティブになっている気がする。もっとチャレンジングなところがあったり,ブレークスルーがあってもいいのではないかと思う。
【小柳主査】  FSは技術そのものを開発するという時間スケールではなく,数年後に実現可能な,ある程度見えている技術を調査検討するということだったと思う。確かにブレークスルーみたいなものは,もう少し明確になった方がいいと思うが,チャレンジングなものは難しいと思う。
【林計算科学技術推進室長】  先ほど,FSのシステムの評価はこのワーキンググループで行うと申し上げたが少し語弊がある。実際は,このワーキンググループで各チームの優劣を付けるのではなく,システムの開発主体が3つのチームの技術的な知見も入れながらどのようなものを作るかを検討し,それをこのワーキンググループで評価するというようになると思う。その意味で,ここではFSの3チームの状況を見て,いつくらいにどれくらいのものが作れそうなのかといったイメージを議論していただくということだろうと思っている。
【宇川委員】  そうであれば,コンソーシアムの考え方とも合っていると思う。
【加藤委員】  先ほどの話で,エクサの段階では,基本的にデータがきちっと並んでいるということをアプリが前提にするしかなくなるのではないかと思っている。それを今回試験的にやってみるということに対しては賛成で,反対しているわけではない。
【富田委員】  アプリ側の意識改革も必要だと思っていて,有限要素法などランダムにアクセスするようなものは使い続けたいという意見も多い。しかし,実際には今後これでは無理があり,このようなやり方でやった方が効率が上がるというようなコンセンサスを得ていくことが重要だと思う。
【加藤委員】  エクサとか10エクサの時代に,ワンストラクチャーで行けるとは思っていないので,上に行くためにはもうこれしかないというのは,それはそれでいいと思っている。もう一つ重要なのは,エクサの時代にはペタがもっと手軽に使えて,それが普及していないといけない。そうすると,このダウンサイジングでは困るというのもある。そこがどうなっていくかを見通さないといけないが,そこが一番難しいところでもあると思う。
【中島委員】  基本的にアンストラクチャードのようなコンピュータにとって扱いにくいデータ構造になった理由は,メモリが足りないということがあった。
 要するに,やり方,考え方を変えるしかなく,例えば,昔からよくあるように,逐次最適化されたものは逐次なんだから,並列で効率的に動かすのは難しいという話と同じように,アクセラレータ最適化でもあると思う。計算が面倒だから,こんなのもう知らんとか言っていると発展はない。そのようなチャレンジを,もちろんアーキテクチャでやるのはそれなりに大変だろうし,アプリ側でのチャレンジというのもあると思う。
【渡邉委員】  佐藤先生の7枚目のスライドにある磁気流体コードや地震波の計算コードは規模が小さいが,これはコアに載せるためということなのか。通常,磁気流体のこのくらいのセル数だと,マックスで5テラバイトくらいになると思う。
【佐藤センター長】  磁気流体コードの場合はグローバルメモリも使っているので,32TB/groupぐらいまでは行く。
【渡邉委員】  地震波の伝搬コードに関して言うと,これは8キロ四方くらいなのか。
【佐藤センター長】  ええ。このような使い方もあるが,本当にやりたいのはもっと大きな高精度のものだと専門家は言っている。ただ,このくらい小さくすると,実時間よりもこのぐらいで動くというのは面白かったということであった。
【松岡委員】  これはオフチップもあるので東工大のコードだと思う。「TSUBAME」でやっているようにレイテンシハイディングすれば,ほぼオーバーヘッドはないので,もっと大きいサイズでも性能が出るかもしれない。コードが小さいからといって,大きくなると性能が出ないというわけではない。
【佐藤センター長】  やり方ですね。
【松岡委員】  隣接通信だけになるので,ネットワークがそこそこあれば大丈夫です。
【牧野委員】  いや,若干B/Fが足りない。
【関口(智)委員】  先ほど,評価用のアプリに加えてデータが重要であるという松岡先生の指摘もあったとおり,いい数値が出るようなところだけを出されては困るので,ここで今後議論していくのであれば,小さなスケールから大きなスケールまで,それぞれ評価をしたものをテーブルにして多面的に議論ができるのがFSの一つの目的ではないかと思う。いい数字だけではなく,そうでない数字もきちんと出していただけると有り難い。
【小柳主査】  もちろん,得意なところが限られるのは仕方がない。
【松岡委員】  ちなみに,アプリFSのミニアプリも幾つかの種類のデータやデータサイズを定義し,それが今のマシンでどのくらいになるかとか,そういったことをデータベース化することで公平な比較になると思う。
【中島委員】  来年度のFSに向けてだが,先ほど平尾先生もおっしゃったように,コンサバティブな部分は多分あると思う。例えば,3つのチームの数値を見比べたときに,ノード当たりのメモリ量とかバンド幅が1桁近く違うとか,電力の問題とか,いろいろなことがあると思う。だけど,例えば汎用の場合,コンセプチャルにこうでないといけないという話の延長線上で決まってくるものもあると思う。メモリ容量とかバンド幅も8チャンネルを16チャンネルにするのは結構大げさな話だと思うが,0.3を0.6にしたら,世の中がどのくらいハッピーになって,その代わり3メガワット必要とか,10メガワット必要とか,チューニングというか,エクスプロアができるような形も考えていただきたいと思う。
【林計算科学技術推進室長】  前回コンソーシアムからの提言にあったが,2018年にエクサを目指すことについて,FSの状況をみてそれが政策的にどうなのかということについても意見を頂けると有り難い。
【小柳主査】  3チームのうち,東北大は100ペタを基本にして,東大はハーフエクサくらいを念頭に置いているように見える。筑波大はピークでエクサというところで,どのくらいを目指すべきか,あるいは,目指せるかという辺りについて意見はどうか。
【宇川委員】  コンソーシアムとしては,技術的な困難はあるにしろ,2018年を目指すべきではないかと言っている。それに対して実現可能かどうかは当然その技術的な開発の速度にもよるので,3チームの方々はそれについてどう考えるのかをまず聞きたい。
【佐藤センター長】  電力評価の状況にあるように,このような形でないと1エクサは目指せない。それがどのくらい価値があるかという話は置いておいて,もし1エクサを2018年に達成するためには,このくらいストリクトなSIMDのアーキテクチャにする必要があるし,逆に,B/Fが外付けのメモリ,つまりインターポーザでつないだところに対して0.05というのはペシミシティックだが,あれはチップの側に余りにもいっぱい詰め込むからである。あれでも1TB/sのシリコンインターポーザのバンド幅を期待しているので,実効効率の議論はあるが,ピークとしては1エクサを目指せると思っている。
【石川委員】  資料の6ページにあるとおり,今想定しているのは2017年度末に量産品ができるという仮定で,その後システムを作り,設置,調整して2018年度いっぱいかかる。「京」のときと同じように段階的に大きくしていくようなことになると思う。ただし,これは2017年の半導体プロセス技術が想定どおりに出てくればということで,ずれ込む可能性もある。
【小林委員】  エクサスケールとか1エクサFLOPSのピークがどういう意味を持つかということを考えたときに,実際どういうアプリケーションで何ができるのか,それを考えると,余り意味がないと言っては何ですが,シンボリックな値というように思っている。我々はアプリの性能としてこのぐらいの実効FLOPSが欲しいから,こういうシステムを作ろうというような考え方で作っている。
【宇川委員】  100ペタFLOPSのシステムであれば,13ページの表にあるとおり,2018年に量産出荷が可能ということか。
【小林委員】  そのロードマップで作れると思っている。
【富田委員】  一昨年度から合同作業部会でコンセンサスを得られたことは,要するに1エクサFLOPSのピークを目指すわけではないということだと認識している。ピークの1エクサの可能性よりも,サイエンスで何をやるか,社会的課題をどう解決するか,そのためにはどのようなマシンを作るかというところから始まっている。その観点からいくと,1エクサがどの時点でできるかという議論はナンセンスだと思う。
【小柳主査】  エクサスケールという言い方をしているのは,その辺のことがあると思う。
【宇川委員】  それぞれのチームが2018年度にどこまでやれるのかということを確認したわけで,1つのチームは100ペタFLOPSであれば2018年にできると,次のチームは300ペタFLOPSまではできる,最後のチームは1エクサまで行くということだと思う。
【小林委員】  システムとして何を評価するかであり,メモリのバンド幅とかI/Oバンド幅とかいろいろあると思うので,そこが抜けないようにしてほしい。
【加藤委員】  2018年にエクサとか300とか100はいいと思うが,その後のことは言及しないのか。つまり,そこが限界なのか,それともその先があるのかくらいは言及しないと,アプリを書く側としては,それに注力していいのかという問題が出てくる。
【小柳主査】  もちろん不確定性がまだ増えるが,コンピュータ技術はここが終わりというのが何回言われたか分からないくらいある。
【加藤委員】  今回だけは本当に終わりじゃないかという気がしている。
【佐藤センター長】  半導体テクノロジが進んでいけば,それを使えるメモリ量に振ればメモリ量が増えるし,FLOPSに振ればFLOPS値が増えるというような話なので,メモリ量を増やすという観点から言えば,今提案しているようなアーキテクチャで収容できるアプリケーションが増えてくるというようなことを期待している。
 例えば,iPhoneみたいなもので思うのは,テクノロジはある段階を超えたときに,人間やアプリケーションに対してフィットする瞬間があるわけで,だから,今は使いものにならなくても,現在のアプリケーションが載って,そのままスケーリングするようなものができるのではないか,その発展段階だと思っている。
【小柳主査】  これもまだ議論を続けなければいけないとは思うが,FSの各チームはここで指摘されたことや,先ほど議論になったB/Fについても整理しておいていただきたいと思う。
 それでは,議題(2)に移りたいと思う。議題(2)では,富士通から「京」の波及効果についてヒアリングを行う予定になっている。富士通の堀越さんから説明をお願いします。

(2)「京」の波及効果に関するヒアリング

資料3に基づき富士通株式会社堀越氏より説明。質疑応答は以下のとおり。

【小柳主査】  プロセッサの開発についてはいつも議論になる部分ではあるが,そのプロセッサを独自開発したことによる発展,買ってきたのではできなかったことなどについて,もう少し説明していただきたい。
【富士通(追永)】  PCクラスタは世の中で一般的に売られているが,それを買ってきて超並列が本当にできたかというと,やはり新しいネットワークや実装も含めたものをやろうとすると,プロセッサも含めてやらないとできなかったと思う。
 スパコンの歴史を見ると,1年間に1.5倍から2倍くらいで性能が上がってきており,どこかが新しいブレークスルーを起こしてそれを達成してきている。今は中国がプロセッサの開発も含めて頑張っていて,そういうことをやっていかないとトップグループを維持できないと思う。その意味で富士通は今回チャンスを頂いて,達成することができたと思っている。
【善甫委員】  ブランドの話があったが,作る側だけではなく,使う側にもそれはあると思う。ほかの人が速いスピードで計算したものをうまく使って,いわばブランドで産業利用をしている。波及効果はこのようなところにもあると思うので,この観点でもう少し話を聞かせてほしい。
【富士通(堀越)】  本来は作る方なので,使う方に関して余りコメントしたくはないが,善甫さんがおっしゃるのはまさに大事な観点だと思っている。一方で,例えば産業応用協議会のような場で,本当にうまく使っている人たちから意見を言ってもらうといいと思う。そのような場面では産業利用への期待も大きいし,成果を期待されている分野だと思うので,是非我々も応援したいと思っている。
【高田委員】  テクノロジーブランドのところで英国HPC Walesの産業育成のことが書いてあるが,これはソフトウェアベンダのことなのか,ユーザ企業の産業育成なのか。また,自治体がやっているのか。
【富士通(堀越)】  全てです。HPCを起点として,例えばソフトやものづくり,そういうものに関連して産業興しをしようということなので,非常に広い範囲だと思う。国と地方政府と大学,それから我々がやっている。
【中村委員】  まとめのところに,関連ビジネスの獲得だけでは採算が困難となっているが,ビジネス的に採算が取れないとなると,いつも税金を投入しないといけないことになる。「京」の次,またその次と行くことを考えると,やはり何らかの形である程度自立した形が望ましいと思う。ここで獲得だけではと書いたのは,ほかのビジネスモデルがあり得るということなのか。
【富士通(堀越)】  本来,サステーナブルにするためにはこれだけで技術が回れば一番いいが,これだけのチャレンジをこの短期間でやるためには,人を掛けながらやっていくというモデルになっており,逆説的な発言で申し訳ないが,国のお金がある程度入らないとサステーナブルになり得ない。このような超ハイエンドの分野に関しては,継続的に支援を頂きたい。
 一方で,FX10という「京」の商用機を作って単品でも売れるようにしているが,まだまだ高いというのがあり,次のマシンではプロセッサを横展開するだけではなく,民間のデパートメンタルなところでも買えるようなものにしたいと思っている。そのためには,例えばアプリケーションとセットにするとか,値段だけの話ではないことは重々分かっているが,そういったところも含めてチャレンジをしたいと思っている。
【秋山委員】  「京」を使っているアプリケーション側の立場としての発言になるが,例えばTofuというネットワークは本当にすばらしいし,非常に安定性の高いマシンだと思う。一方で,CPUから国内で作っていることの大きな重荷の一つとして,コンパイラの開発の問題があると思う。LINPACKは走っても,アカデミア等で標準的に使っているC++のパッケージをコンパイルするのに2か月もかかると,研究者にとって大きな負担になる。コンパイラの将来について,富士通としていかがか。
【富士通(追永)】  その点に関しては非常に申し訳なく思っている。富士通はベクトルからスカラになったが,スカラの方がもっと幅広いユーザに使ってもらえるだろうということでやっている。残念ながら,「京」のときにはコンパイラにそこまで手が回らなかったというところはあるが,次のシステムはC++に関してはかなり改善させており,期待に応えられるレベルになっていると思う。
 プロセッサを開発していることと,コンパイラ部隊を持っていることはかなり強みになっている。コンパイラに関して言うと世界でも少なくなってきたが,そこで我々として特徴を出していきたいと思っている。
【村上委員】  コンパイラやプロセッサのことは,大学と企業との間の人材供給に関する,企業側のニーズに対して大学が応えられてない一つの端的な例になっているのではないかと思う。その意味では,それぞれの企業においてこういった技術を継続的に発展させ,ブレークスルーを生めるような人材を大学にもっと求めるような発言をしていただいた方がいいと思う。
 国内の大学に限定すると,情報工学などの学生数はほとんど横ばいか減りつつある中で,IT関連の就職先は非常に多岐にわたっており,かつ,研究分野としてのプロセッサなりコンパイラを研究室のメーンのテーマにしている所はぐっと減っている。企業には,この分野で求めているような人材がほとんど行ってない。その中でコンパイラやプロセッサを頑張れというのはある意味酷かもしれない。10年,20年,継続的にやっていくのであれば,大学と企業との間でどう連携していくのか。単なる新しい技術の開発だけではなく,人材供給についても外に向かって発言いただければと期待している。
【宇川委員】  中村先生の発言とは意見が違うのだが,HPCに関して,特にトップエンドに関して企業だけで採算が取れるというのは成り立たないと思っている。それは企業がやっている強い技術をもとにして,それを引き上げるところを国が支援するもので,これからも支援していくべきだと思う。アメリカのコンピュータの歴史を見ると分かるが,ENIACの時代から同じであり,メーカだけに任せておいたら今のような発展はなかったと思う。それは日本においても同じで,真に必要な技術を引き上げるためには,そこに国が投資するのは国の責任だと思う。

(3)リーディングマシンについて

資料4に基づき林計算科学技術推進室長より説明。質疑応答は以下のとおり。

【牧野委員】  複数システムに関する前提が現実的かどうかよく分からないが,それぞれに向けて専用システムを同じ性能を目指して作るか,同じコストを配分するかによって話が変わってくる。なので,まだ少し現実的な議論になっていないという気がした。
【小柳主査】  イメージでいうとイメージ1と3を比べているような感じになる。複数というのをこのように5つにする場合と,2つくらいを考えるとまた大分違うが,この辺りについて意見を頂きたい。
【渡邉委員】  複数のシステムというのは,同じ場所に違うものを置くのか。例えば3.11のときやその後の電力問題など,リスク分散ということも考えた方がいいと思う。
【林計算科学技術推進室長】  場所についてはまだ考えていないが,複数の場所を想定していた。もし,同じ所に置くのであれば,運用費は同じくらいになるかもしれない。
【小柳主査】  重要な視点だが,それはまた別の視点だと思う。
【秋山委員】  この資料は定量的にはちょっと変かもしれないが,定性的には挙げるべきポイントが挙げられており面白い資料だと思う。ただ,定量的な話になった瞬間に,この5つの項目の間のバランスが余りにも極端に違うと思う。例えば,「メモリ容量が大きくなるため,大きな規模の問題サイズを計算することが可能」とあり,これは全くそのとおりだが,我が国の大危機が来て,1台にまとめておいたら助かったのに,分散していたからできなかったというケースが本当にあるや否やということを思う。
 つまり,総計算量というのは我々が国の発展のためにこれからロードマップを描いていかないといけないことなので,その方が大きいだろうと思う。ただ,最後の「開発費のコストが高くなる可能性がある」これがものすごく大きな項目で,定量の話になった瞬間に難しくなる資料だと感じた。
【小柳主査】  そんなに厳密に作れる話ではなく,そのことを頭に置いた上で,リーディングマシンのイメージについて意見を頂きたいと思う。初期の議論では,エクサというある意味で特殊というか,非常に先端的なものはイメージ1のような,汎用的マシンでは考えにくいのではないかということから始まっていったと思うが,フィージビリティースタディや今回の資料もあるので,もう一度考え直して,中間報告の路線を出していきたい。
【村上委員】  我が国の「京」とアメリカのマシンとの違いは,「京」の場合センター運用を想定しているということであり,それが汎用という言葉で言われる。それに対して,アメリカはどちらかというとラボマシンという位置付けで,「京」のような形での運用は余り想定していないということがあると思う。それが結果として資料4のような議論にも関係してきていると思う。センター的な運用を考えるのであれば,どうしてもここでいうところの一つの汎用システムみたいなものになると思うし,ラボ的なマシンであれば,複数の特徴あるシステムにもなり得ると思う。
 資料4に関しては,汎用システムと複数の特徴あるシステムをもう少し具体的なマシンイメージまで落とし込まないと,定量的な話はできないと思う。
【小林委員】  汎用というのはつかみどころがない言葉で,我々も特殊なマシンを作っているつもりはなく,汎用を目指している。もちろん,得意不得意なアプリケーション分野はあるが,汎用性は失っていない。そのときに,汎用をどう定義するのかが見えないという印象がある。
【石川委員】  結局のところ,アプリケーションから見たときにどれだけのメモリ,問題サイズで,どのくらいの実行時間で終わらせたいかというセットがあったときに,そこからマシン構成を考えていくのが,一番まっとうなマシンを設計するときの評価指標になる。それがそのままうまくいくかどうかは別問題で,アプリケーションや分野が違うものに対して,資源割当てをどうするかというところに結局のところは行き着く。このようなことを議論していかないと,結局「京」のときと同じような話になるような気がする。
【小柳主査】  「京」のときと同じというのはどういうことを意味しているのか。
【石川委員】  システム全体でB/F値がほぼ一緒であり,ほとんどのアプリケーションはそれに律速されて若干の違いはあるにせよ10倍も違うようなことはなく,ほとんど差がなかった。通信もFFTみたいなものだと,そんなに大きなスケールのものを入れられるのかといった議論があった。また同じようなことが起こりそうな気がしている。
【小柳主査】  御存じない方もいるかもしれないが,今の議論は「京」の初期に複合型システムがあり,ベクトルとスカラといったときの話のことである。あのときの計画は0.5ペタのベクトルと1ペタのスカラとピーク20ペタの専用システムというのが初期の案だった。
【石川委員】  あのときと違うのは,アプリケーションで既に成果が出てきているので,ちゃんとアプリケーションドリブンでやっていけたらと思う。だからこそ,去年の3月に白書を出し,こうやってそのアプリチームも立ち上げてやっている。具体的にこの後どうやって最適なマシンを決めていくのか道筋が見えていない。
【佐藤センター長】  効率について余り議論がないことに違和感がある。つまり,何でCPUだけを言うのかという話もあるし,汎用システムだからといってEとかAみたいに大きくぶれるのかという話もあるし,専用システムになると本当に40%出るかという話もある。「京」を見ても,メモリバンド幅に不満を持つ人はいるが,分野によってそんなに効率はばらついているのか。
【青木委員】  ユーザ側から見ると,汎用マシンを作ってもそこそこの性能が出るだろうということは分かるのだが,その分野に合ったものを作れば,汎用マシンと比べてもっと価格性能比の高い計算機が作れるのではないかと思っているので,複数ということを言っている。総予算が決まっている場合に,汎用1台だけで達成できる総演算量に比べて,複数でやった方が同じコストでははるかに高い総演算,実行演算が得られるのではないか,という点を心配している。複数作る場合の問題点は,複数の国産のスパコンを同時に作る技術力,特に人的資源が,現在の日本にあるのかということであったが,今日のFSを聞く限り,複数台を作る能力はあるということで安心した。
【宇川委員】  コンソーシアムの議論を前回紹介させていただいたが,この点はコンソーシアムでも随分と議論になった。改めて紹介させていただくと,頂点に立つシステムは世界トップレベルの演算能力を維持するものであり,それを1台作って,ピラミッド構造にする。第2階層にはそれではカバーしきれない,一定程度のコミュニティをカバーするようなもの,あるいはチャレンジングなシステムを配置するという提言だった。そのときに,世界トップのシステムというのは注意書きがあって,圧倒的な演算性能によって,様々な最先端の成果創出を可能とする総合性能と書いてある。総合という文字はすごく気を使って書いていて,単にCPUの演算性能だけではなく,場合によってはI/Oもある,また計算量の観点もあるし,実効性能の観点もあるといったような意味で総合性能と言っている。
 そのような観点で本日の横長の資料を見ると,実効性能,問題サイズ,計算量がそれぞれ書いてある。ただ,5つ作ったときに同じコストで同じような40%という実効性能が得られるかどうかについては,確かにいろいろ疑念があると思う。ただ,全体的に考えると,ここでは汎用と書いているが,一つのシステムがある程度のアプリをカバーできるのであれば,それを1台世界トップのピークマシンとして作り,そこで高い総合性能を持ったシステムとして働かせるというのがいいのではないかというのが,コミュニティとしての意見である。
【室井委員】  資料4は理論計算性能が同じという前提で書かれているが,実効性能がこれだけ差があると,当然ばらばらでやって方がよく見えてしまうというのは当たり前だと思う。今までの議論を拝見していると,解決したい課題,問題サイズが決まっている中で成果を上げたいというところがスタートだと思うので,理論計算性能が同じなのではなく,やりたい計算が同じ場合に,どちらのコストが安いか,効果的かといった議論にしていかないと結論が見えないのではないか。
 もう一点は,汎用の場合は大きなコミュニティを作ることが可能で,似たようなアルゴリズムがたくさんあり,そういうところの相互理解なり,外部アプリ化が促進されるというような議論もあった。このような直接数字では見えてこない間接効果もあるのではないかと思う。
【松岡委員】  「京」やほかのマシンの経緯を見ると,リーディングマシンというのはすごくお金を掛けるし,リスクが大き過ぎるので大きな冒険ができない。それができるのはもう少しコストが安いセカンドティアになると思う。そのとき,「京」や今までのリーディングマシンの効能は,方向性を決めるというのが非常に大きいと思う。「京」の開発でいろいろな技術ができてきたのはすばらしいが,我が国のHPCにとって最大の効能は,やはり超並列化を推進したことだと思う。アプリの研究者もようやく超並列に向いてくれて,「京」では若い人たちが超並列のコードを書いている。このようなグローバルスタンダードという方向性に我が国を持ってきてくれたのが「京」の大きな効能だと思う。
 アプリケーション側にはそのような道しるべを示さないといけない。つまり,我が国としてはこういうマシンができ,こうやればサイエンスで性能が出せて,しばらくはこれでうまくいくというようなことを示す必要がある。次のマシンをやるときに,マシンを作る側から方向性を示さないと,リーディングマシンというのはただ単に買ってきてもいいものになってしまう。
【小柳主査】  それは同時に,コンピュータ技術でも同じことがある。
【松岡委員】  アプリケーションの研究者とよく相談してやらなければいけないが,超並列という「京」のメッセージは非常に分かりやすく,次のマシンのメッセージは何かということが重要になる。
【秋山委員】  FSでは3つのタイプのアーキテクチャが検討されているが,その中で,石川先生のところを汎用と呼ぶかどうかは分からないが,そのタイプを作らないということは多分ないと思う。ほかのB/F値が大きなマシンと,アクセラレーションができるマシンがないとどのくらい困るのか,汎用のマシンの効率よりも1.5倍とか2倍高いだけだったら作らない方がいいと思う。
 例えばそれが10倍とすると,予算は10分の1でいいだろうというのがまずある。10倍速くなるなら,10分の1の規模でメーンのマシンと同じぐらいのことができる。しかも,それを言うときには,アクセラレーションを使う分野,B/Fが高いベクトル計算をしなければいけない分野が3分の1ある場合にそうであって,もし更にそれよりも小さいのであれば,10分の1よりももっと小さい投資でいいということになると私は思う。
【加藤委員】  大分前の段階だと,このようなコンセプシャルな議論で固めるのは重要だと思うが,既にもうFSの結果がある程度出てきているので,もう少し具体的に議論をするわけにはいかないのか。つまり,この場でこういうものだと言っても,実際に予算をどうするかとか,いろいろな問題があり,特にセカンドティアをどうするかという話も重要で,前に進めない。
【小柳主査】  今,具体的な話ができるかというと,まだそういう段階でもないということはある。まだ議論しなければいけないとは思うが,これとも関連があるので先に進めたい。先ほどFSのところで,要素技術の話が出てきたが,我々としてキーとなる要素技術をどう位置付けるかは大変重要な問題で,それを踏まえて意見を頂きたい。
 論点整理の中では,リーディングマシンのハードウェア,システムソフトウェアについて,我が国として強みのある技術かどうか,国家安全保障上保持すべき技術かどうか,スパコン開発でキーとなる技術かどうか,民間に展開できる,ビジネスとして成り立つ技術かどうかなどの観点から,重点を置く技術を定め,戦略的に進めるべきである,と書いてある。先ほどのリーディングマシンをどうするかという議論ともつながってくるが,要素技術として何をすべきか,それはどうしてなのかということについて,皆様の意見を聞きたいと思う。FSの中で出てきたのは,プロセッサはもちろん,インターコネクト,省電力化技術,システムソフトウェア,耐故障性というようないろいろな技術がある。
【小林委員】  3次元実装技術がこれからどうなるかは確かに見えないところもあるが,ただ,2次元の10ナノ以下では,まだまだデバイスの技術が分からないし,それ以前に,今までシュリンクすればコストが安くなっていったという式が成り立たなくなっている。そのような状況で,3次元実装技術は日本でもいろいろなプロジェクトが出ており,それらをうまく活用してFSと関連付けられればというように思って取り組んでいる。
 コストに関してはどこが最初に口火を切って,一気にラーニングカーブ的に安くなるか,ここ数年の動きが重要だと思っている。また,ファブがみんな海外に行っているということになるが,その後工程として3次元加工は日本でできる技術だと思っている。チップは作らせて,それを張り合わせるのは日本で行い,そこでビジネスをするということもあるのではないかと思っている。
【佐藤センター長】  要素技術に関しては,プロジェクトの中での開発は余り考えていない。10ナノはかなりフィージブルだと思うし,2.5次元もそれなりに使えると思う。ただ,チップから光を出す辺りがクリティカルなところだとは思う。このために無理して開発するという形の提案はしないつもりでいる。
【小柳主査】  つまり,市場の技術の成熟をしたものを利用するというような趣旨ですね。
【石川委員】  私はシステムソフトウェアが専門なのでその話をすると,先日も国際ワークショップを開いて,アメリカとの間でシステムソフトウェアの国際協力が具体的な話になってきている。我々がアーキテクチャを提案して実際に作っていくのは重要だが,その結果としてガラパゴス化してはいけない。そのためには,システムソフトウェアスタックのところで共通のものを作って提供していかなければいけないと思う。例えばMPI通信ライブラリにしても,初期の頃は日本のメーカも対応していたが,最近はほとんど対応しておらず,アメリカとヨーロッパ任せになっている。そうなると,オンタイムでシステムソフトウェアスタックが提供できなくなり,新しいシステムソフトウェアスタックでアプリケーションを作られてしまうと,後追いになっていく。幾ら先進的なハードウェアがあっても,その上で動いているアプリケーションは1世代前のアプリケーションということになりかねない。コンパイラとアーキテクチャも同様で,例えばコモディティ系のプロセッサの細かいところは教えてもらえないので,結局システムソフトウェアを作るといってもかなり厳しくなる。アーキテクチャを持って内部がどう動くか,何が問題になるのかを一緒にやっていけるような体制ができなければいけないと思う。
【小柳主査】  ソフトウェアをちゃんと開発できるようにするためにも,プロセッサを開発することが必要だというふうに聞こえたが,そういうことか。
【石川委員】  そうです。だから,汎用の場合はコモディティに負けてはいけないと思っている。
【関口(智)委員】  ネットワークに関してはノード間までしか書かれていないが,外部とのシームレスな連携が重要になってくる。そういうところの技術についても技術項目として考えていただければとは思う。特に,チップ間も含めて内部が光を使ってくるのであれば,できるだけそういうものが外に出ていくとか,親和性を考えていくのも必要ではないかと思う。
【松岡委員】  要素技術については当たり前の話であり,全く課題になっていないと思う。例えば省電力といっても,昔からECLからCMOSに行ったのも省電力だった。もう少し技術的に精緻にやらないと,これではジェネリック過ぎるのではないか。
【中村委員】  要素技術としてハードウェアとソフトウェアが分かれていること自体余り気に食わない。ハードウェアを作っただけで解決する課題はなく,例えば省電力制御やストレージの問題もシステムソフトウェアと一緒にやる必要がある。場合によってはアプリケーションも巻き込まなければいけないような課題も既に見えているということを言いたい。
【石川委員】  そこに関しては,我々はco-designという形でやっているし,省電力に関しては中村先生もいろいろとやっている。書き方として分けるとこうなってしまうということだと思う。
【松岡委員】  つまり数値目標に対して何がポイントになるかであり,例えば省電力に関して言えば,システムソフトウェアレベルのアクティブ制御はできてない。だから,それをやっていく必要がある。別な観点では,省電力の課題はデータのムーブメントにほとんど電力が食われることになるので,データを動かさなくていいアーキテクチャとそのシステムソフトウェアをどうするか,言語やスタック全体も含めて,これが課題になる。もちろん全部やればいいに決まっているが,将来のテクノロジーマップに対して,何が問題でどう技術開発していくかを詳細化しないといけないと思う。
【小柳主査】  国家的な技術開発として,どこに重点を置くかは確かに重要な問題だと思う。ここはもう少し精密化しなければいけないと思うが,皆さんの意見を見た上でまとめ方を考えたいと思う。
【林計算科学技術推進室長】  これは国の政策報告書なので,どこまで技術的に細かいことを書いていくかは判断があると思う。何人かの先生にも手伝っていただいて,資料を精緻化していきたいと思う。
【小柳主査】  中間報告案についても意見交換したかったが,中間報告案は,論点整理をベースに議論を深めて作っていくことになる。項目3の将来の我が国における計算科学技術システムの在り方と,項目4の計算科学技術に関する研究開発の方向性については今日の議論も整理して,また,FSの議論も取れ入れてまとめたいと思う。
 項目1の国内外の動向と,項目2の利用状況,今後の必要性については,いままでかなり議論してきているが,必要な修正はしていきたい。また,項目5の利用の在り方と,項目6のその他については,これも重要な問題とは思うが,とりあえず中間報告の段階ではそこまで力を入れられないので,最終報告で精緻化していくように考えたいと思う。
 最後に,事務局から1点確認があるそうなので,林さんから説明をお願いします。
【林計算科学技術推進室長】  中間報告をまとめていくに当たり1点確認したい。論点整理の2ページ(2)国内の状況で,『「京」を含め,20ペタFLOPS超と推測されるなど,計算環境の整備は世界上位の水準に戻りつつある』と書いている。これは議論の中で意見があったもので,その根拠としては,「TOP500に対する我が国のスパコンの性能割合は,2000年代初頭には20%を超えており,2000年代半ばには6%を切るところまで低くなっていたものの,2012年6月時点では15%近く」のように記載している。
 他方,この議論をしてから時間がたって,11月のTOP500の結果を見ると,参考資料2にあるとおりやや低下傾向になってきている。このグラフはTOP500のそれぞれの国の計算能力合計の割合で,アメリカは大体50%をキープしており,ヨーロッパは20%くらいになっている。日本の場合は,2000年以前は30%を超える時期もあったが,1996年のCP-PACSや2002年の地球シミュレータ,2011年の「京」で伸びることはあるが,その間は谷になっており,全体としては右肩下がりになっている。このような状況もあり,「世界上位の水準に戻りつつある」というのは事実関係として適切ではなく,長期的には減少傾向というように書いた方がいいのではないかと思う。
【小柳主査】  私がいつも言っていることではあるが,一点豪華主義をやってきたつけがこういう形になっていると思う。「京」を始めるときからロードマップに従った開発計画がなければいけないということを言ってきたが,我々は次のシステムでそれを今やっていることになる。ということで,ここは文章を少し変えたいと思う。
 それでは,これまで頂いた意見を事務局で整理して,この中間報告案の完成度を高めていきたいと思う。またいろいろお伺いすることもあるかと思うが,協力をお願いしたい。
 議題は以上なので,事務局から次回の連絡をお願いします。

(4)その他

 村松計算科学技術推進室長補佐より,次回の日程(4月19日金曜日,10時,3F1特別会議室)を報告。また,林計算科学技術推進室長より今後の予定を報告。

小柳主査より閉会発言

 

お問合せ先

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

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

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

-- 登録:平成25年05月 --