平成24年8月10日（金曜日）10時～12時
文部科学省 第二講堂（旧文部省庁舎6階）
小柳主査、秋山委員、天野委員、宇川委員、加藤委員、小林委員、坂内委員、関口（智）委員、常行委員、富田委員、中島委員、牧野委員、松尾委員、村上委員、室井委員、渡邉委員 （HPCI計画推進委員会）土居主査 （説明者）東京大学 平木教授
森本審議官、下間情報課長、林計算科学技術推進室長、村松計算科学技術推進室長補佐
林計算科学技術推進室長より、資料1に基づき説明。また、システム設計研究チームの説明を、東京大学の平木教授より資料2、牧野委員より資料3、及び小林委員より資料4に基づき説明。質疑応答は以下のとおり。
【加藤委員】FSをやらないとわからないということもあると思うが、目標としている具体的なスペック、演算性能とメモリ性能とメモリ容量を教えてほしい。
【富士通】レイテンシコアについて、富士通からお答えします。平木先生から紹介があったように、SDHPCでつくられたロードマップ白書のアプリケーションが要求しているスペックが、レイテンシコアで目指しているスペックになる。具体的には、総演算性能としては幅があるが、1ExaFlops前後を目指している。総メモリ帯域、容量、インターコネクトについては、従来の演算性能に対するバランスをそのまま拡張したあたりを目標としている。
【加藤委員】メモリ帯域と容量は。
【富士通】0.5ぐらいのところ、メモリ容量は100PBくらいのところがターゲットになると考えている。
【平木教授】今のが概略仕様ですが、レイテンシコアは浮動小数点性能を伸ばせばいいという立場ではなく、幅広いアプリケーションを広範囲にカバーすることを目標にしている。そのためレイテンシ性能、整数性能についても目標を考えており、その目標を設定するのが今回の調査研究の大きな目的だと思っている。
【牧野委員】筑波大学のチームは、スライド後半の「もうちょっと具体的なイメージ」に、チップ当たりの演算器とメモリサイズが書いてある。1チップが15ミリ角くらいとして、想定が16TFlopsから32TFlops程度、メモリサイズが256MBから512MB。消費電力当たりの演算性能が、100から200ぐらいを実現することを目指している。今の数字を1万倍とか3万倍したところがトータルシステムの目標値になる。
【加藤委員】これだけメモリが小さいのは、帯域は求めないということか。
【牧野委員】オンチップのメモリに対しては4B／Fぐらい、要するに古典ベクトル並みの帯域を持たせるということであるが、外側に対しては0.01ぐらいまで落ちても仕方がない。
【小林委員】ロードマップに100PFlopsと出ていたのが一つの目標であり、100以上1EXAの範囲でどういうシステムが開発可能かを調査研究することになる。バンド幅に関しては1B／F以上を目指すということになる。メモリ容量は、アプリケーション側からは1Flops/Byteといわれているが、そこから大分削る必要があると思っている。
【秋山委員】今回の開発ではco-designということが重視され、去年はアプリケーション側とシステム側の集まりを何度もやっている。今日の3つのチームもアプリの先生が多く入っていてよい体制だと思うが、一方で、アプリの方からお願いしたもののうち、落ちているものが幾つかある。
1つはバルクジョブであり、例えば「京」を全系使ってなし遂げる科学的なものもたくさんあるが、10分の1、100分の1しか使えない場合でもそれをどう生かすかということが、アプリ側からは結構あった。また、今日の牧野先生の発表の中で、全系でやるようなFFTについてはあきらめざるを得ないということがあり、もちろんそれは理解しているが、100分の1ぐらいのところでFFTが動くとサイエンスが進むというような発言もあったと思う。いろいろな意味で、アーキテクチャが一枚岩じゃない階層型という話がアプリ側から出ていたものが落ちている気がする。
私個人としては、データインテンシブの扱いが浅いような印象がある。富田先生のアプリとそういうやりとりを深めていただければと思っている。
【牧野委員】今の点に関して、バルクジョブというか、小規模なシステムに関する開発目標は、今のGPGPUに対して競争力があるようなシステムで、小規模な構成でも限定されたアプリケーションでは高い性能が出せるようなシステムが、マーケティング的なことも考えて目標になっている。
FFTに関しても若干検討しており、512の3乗とか1,000の3乗ぐらいまでは、演算加速側のネットワークでどの程度の性能が出るかを検討していこうと考えている。ただし、チップ間ネットワークによって性能がリミットされるので、あまり高くはならないが、非常に小さい構成の場合には、ある程度の効率は期待できると考えている。
【平木教授】時間の都合でプレゼンテーションでははしょっているが、レイテンシコアということ自身がある意味データインテンシブ、アプリケーションを正面に見ているわけで、階層的なファイルシステムをいきなり、いかにそのデータをストリームラインに流すか、また、それを処理するための命令、特に浮動小数点でない命令をいかに効率化するかということは、最も重要な課題と考えている。
【関口（智）委員】平木先生からレイテンシコアに関してプレゼンテーションがあったが、以前はむしろ演算加速機構を持つ方式派だったのではないかと思っていた。今回、レイテンシコアのチームに入って進めようとされているが、どういうところが本質的に今後は変わっていくと考えているのか。
【平木教授】 その2つのアプローチは両方とも非常に重要なもので、筑波大がやっている演算重視のタイプは、演算器自身をいかに低電力にして、データをストリームラインに流すかということが課題である。レイテンシコアについてももちろんある程度の加速は前提になるが、そこでは共通の知見が使えるので、共通でない知見は、あくまでほんとうにレイテンシが問題になるような、ストロングスケールに必要なもののアーキテクチャ要素を考えるということが必要になる。そこについては、現在、国産のプロセッサはややおくれをとっている面があるので、ここを強化することが、全体の底上げをするのには一番有効ではないかと判断したので、そこに力を入れたいと考えている。
【関口（智）委員】そのかぎになるのが、先生のご担当のところだと特にコンパイラということだが、それがブレークスルーになると考えればよろしいか。
【平木教授】ブレークスルーの要素は2つあり、1つがコンパイラ技術、特に最適化をどうやってするか。もう一つがマイクロアーキテクチャ技術で、いかにベースの性能を上げるかというこの2つで、大体、効き目は半々であると考えている。
【牧野委員】マイクロアーキテクチャという話があったので、性能予測の手法に関してお伺いしたい。資料2のスライドの11ページ目に性能予測手法があり、詳細プロファイラとなっていて、これは実機でやるように見えるが、想定する新しいアーキテクチャでのシミュレーションという感じでは必ずしもなく、実機でやることになるのか。
【平木教授】手法としては、実機を用いてプロファイリングをとることによって、各要素の基本データを得て、次のHPCIに適するアーキテクチャの性能予測を行うというモデルを打ち立て、そのモデルによって将来の性能予測を行うのがここでのアプローチです。
【牧野委員】マイクロアーキテクチャのサイクルベースのシミュレータではやらないのか。
【平木教授】私のところではやるが、ここは情報基盤センター担当の部分なので、それはやらないと思っている。
【小柳主査】平木さんのところでお伺いしたいのですが、重要な1つのポイントは、チップ内のメモリの利用で、それはいろいろな技術的な課題を含むと思うのですが、その辺についてはどうか。
【平木教授】チップ内のメモリを高効率に利用するというのは2つのアプローチがあって、1つはアプリケーションオリエンテッドに階層キャッシュを使っていく、もう一つは、もっとベースになるキャッシュシステムの性能自身を上げていくというもので、例えばキャッシュのプリフェッチングとかリプレースメントポリシーとか、そこからのメモリチャネル、又はマルチコアになるのでNOCへのインジェクションの機構とか、そういう基本的な部分を今よりも数倍上げないと、少なくとも今から5年後、10年後の世界トップレベルの性能にはならないと考えている。
【常行委員】ユーザー側から見ると、これがどれぐらい使いやすいシステムになるかというのは大変興味がある。例えば、コンパイラの話が平木先生の話の中にかなり強調されて出てきたと思う。牧野先生の方では、アーキテクチャ、ハードウエアは印象が残ったが、コンパイラのところが私はよくわからなくて、どうやって使うような形をイメージしているのか、どこまでユーザーに努力を要求するようなシステムを想定されるのか、その辺のご意見を……。
【平木教授】まずコンパイラについては、今回の調査研究は期間が短いので、その期間中に実際にユーザーが使えるコンパイラができるとは考えていない。ただ、現状、コンパイラがよくなければ、どんなすばらしいアーキテクチャでも結局、使えないものになってしまうので、どこの部分の最適化、又はコンパイラの方針が、全員がハッピーになる方向につながるかということをこの中で明らかにしたいということで、その意味では、常行先生のご期待にこたえるものではないかと考えている。
【牧野委員】我々のところは、メモリ削減型と演算重視型の2つであり、演算重視型はアプリケーション中で特に演算が重い部分、ほとんど行列演算ですが、そこを重点的に実行することになる。ある意味、そこだけサブルーチンを書きかえて、アルゴリズムは変えないという形の使い方、これはGPUでやっていることですが、そういったイメージと変わらない。
メモリ削減型の場合は、アプリケーション全体というかデータ全体が向こう側にあるので、もう少しコンパイラを考える必要がある。この場合には、古典的なSIMD型の計算機上でやっているようなプログラミングができるが、1つ違うのは、メモリ階層が浅いのでコンパイラはあまり大変ではない。そこが非常に違うところで、アプリケーションが楽になるとは言えないが、コンパイラ屋さんは楽になるので、結果的にアプリケーションも比較的苦労は少なくなると思っている。
引き続き富田委員より、資料5に基づき説明。質疑応答は以下のとおり。
【渡邉委員】ミニアプリでの評価という話があったが、最終的にはフルアプリでもやるのか。地球科学の場合、ミニアプリまで落とし込めば、変数は数十で済むが、実際のフルセットだと150から200になってしまう。
【富田委員】例えば、5年から10年後にこういうサイエンスをやるために、こういうアプリケーションが必要であるとなったときに、気候システムのような非常に複合的なコンポーネントの場合、オプションがものすごくたくさんある。その中で5年後に行うパスをつくってもらう。その意味では、ものすごい行数にはならないと思っているし、同時に、各コンポーネントは、ある程度ブロック化したものを考えている。
つまり、ループ単位のカーネルではなく、力学過程、物理過程を一括で考えたり、そういう形でミニアプリというように考えている。
【室井委員】提案システムというのは、この前にお話があった3つのうちのそれぞれどれか。それぞれのアプリに向いているシステムで評価するということか。
【富田委員】そうです。基本的に3つの提案システムの評価になるが、あるアーキテクチャに特化したアプリケーションで評価するのではなく、ベースラインとして、チューニングされてない真っ白な状態のものを整備する。その中で、各システム評価の人たちに渡して、自由にシステムのやりたいようにやってみてもらう形になると思っている。
【室井委員】co-designと言ってはいるが、実際はアプリ側がコードを渡して、あとはよろしくと言っているようにも聞こえなくもない。
【富田委員】どの部分ですか。
【室井委員】例えば、ミニアプリとかフルセットでもいいが、どのカテゴリに属するか、あるいは3つの提案システムで評価するというところが……。それとも、もう少し柔軟に3つのシステムに向けて最適なメリットが享受できるようなことまで考えてということか。
【富田委員】もちろんそうです。システム評価になった段階では、各チームとの連携は十分に考えていますし、co-designの定義にもよるが、少なくとも、ベースラインは絶対に必要なので、そこから各システム評価の人たちと連携しながら、そのシステムでフルに性能が出せるにはどうすればいいかを一緒に考えていきたいと思う。
【村上委員】システム設計3チームとアプリとの連携ですが、システムの性能に関しては実機がないので、あくまでも推定という形だと思うのですが、推定する場合には結果の検証が必要だと思う。今の話だと、推定のところをアプリチームとシステム設計チームが協働でやるように聞こえていて、もちろん内部ではその結果の正当性をチェックすると思うが、独立して結果の正当性についてバリデーションするという形での連携も必要と思う。バリデーションについてはどのようにするのか。
【富田委員】バリデーションは、物理的な結果のバリデーションという意味か。
【村上委員】 あるシステムではこれだけの性能が出ますという推定がほんとうに妥当かどうかということ。これは実機がないので非常に難しいが、例えば、平木先生のところでは、今ある実機でプロファイリングをとって、それで外挿するような何らかの手段をとるのかもしれないが、そういう形で正当性について……。
【富田委員】その部分はシステム評価をするためのツールが一つの試金石だと思っている。ここは東工大の松岡先生に主に担っていただいているところだが、現状のツールだけでよいのかという議論もあるし、少し手を入れて開発しなければいけないところだと考えている。
【小柳主査】先ほどの室井さんの質問にもあったが、アーキテクチャからアプリへのフィードバックをどの程度まで考えるか。つまり、アーキテクチャに即したモデリングなりアルゴリズムということも、co-designまで行くと大変だと思うが、その辺についての可能性はどうか。
【富田委員】個人的には、それも含めてやっていかなければいけないと思っているが、今回のFSは短期間なので、現行のアルゴリズムで評価していく。もちろん、分野によって、そういうフィードバックはあると思うが、全ての分野においてそうかというと、時間的には厳しいと考えている。最大的に効率を得ようとすれば、基本的には今のアルゴリズムがベースになっていくと思う。
【加藤委員】先ほどのco-designの話ですが、大きな意味ではco-designは成り立っていると思う。もともと、アプリの方が分析して4つのカテゴリに分け、それを受けて、それぞれのチームが概念設計を始めている。つぎにアプリの方が、将来的な代表的なアプリに関して、カーネル部分を中心としたミニアプリをつくる。それをまたシステム側に渡して、システム側が評価する。アプリ側が直接自分達でシステム評価することは無理だと思う。むしろ、そこはシステムに任せしてしまい、返ってきた結果を見て、これではまだ足りないから、では、アプリとしてはこうしようとか、システムにもう少しここを頑張ってもらいたいということをやったほうが現実的だと思う。
【宇川委員】システム検討について、それぞれの目標を聞くと、あたかもできるような気がするが、実際はそうではないはずであり、そのときに一番肝心なことは、できるだけ早い時期にアプリのコア部分を評価して、どこに技術的な課題があるかということを踏み込んでアイデンティファイすることではないか。それを踏まえて、どこをどう克服すれば目標に達するのかを考えることが大事だと思う。
それをする上で、最終的なアプリチームの評価と切り離してはうまくいかないのではないか。システム側にもそれぞれアプリの方が入っているので、富田さんもおっしゃっていたが、早い時期から、うまく情報交換、連携をとっていくことが大事ではないかと思う。
【富田委員】おっしゃるとおりだと思う。そういう意味で、連携に関しては現在、4チーム横断的なワーキンググループのような形で、お声がけさせていただいている。
林計算科学技術推進室長より、資料6に基づき説明。質疑応答は以下のとおり。
【渡邉委員】リーディングマシンはLinpackにとらわれないと理解してよいか。以前、計算科学技術推進WGで「Linpackにとらわれるな」と言い続けたが、議事録からも消された。
【小柳主査】もちろん、それはここの議論になります。
【宇川委員】無視はできないと思う。Linpackは必ずしも実際に使われているアプリではなく、非常に簡単化されたものであるというのは事実ですが、Linpackは巨大なシステムが数十時間動かなければいけない。スパコンの一つの基本要件は、きちんと長時間運転できること。更に、人工的なアプリであるかもしれないが、それなりの性能をきちんと出せることが用件になると思う。その意味で、Linpackを無視して、Linpackは出ないけれども、ほかで性能がいいからこれでいいという言い方は難しいと思う。
【平木教授】Linpack無視というのは議論のあるところで、それをとったときに、何か客観指標が残るかということが問題になる。単にサンエンスが進むということを目標にした場合には、成果があいまいになるので、客観指標にこだわるべきだと思う。
【渡邉委員】その客観指標にLinpackを使うというのは理解できない。確かに「京」は29時間連続運転したが、実際にはほとんどのLinpackは絶えずバックアップをとって、ひどいマシンでは何か月もかかってやっているのもある。アメリカもLinpack競争からは外れようとしている。確かに何か言いたいときに客観指標は欲しいが、次のリーディングマシンといったときにLinpackが指標というのは反対である。
【小柳主査】この定義にはLinpackとは書いていないが、議論にあったように、何か数値目標的なものとしての目安というのは……。ただ、エクサまでいくと、従来のLinpackが動くかどうかというのは、かなり問題になると思う。
【中島委員】結局、ピークFlopsをどう考えるかということになる。LinpackはピークFlopsに対して「京」の場合は9割、世の中の一番低い値で5割弱のところが出ているわけで、ピークFlopsをたたき出すに近い値、あるいはそこそこの値をたたき出すために必要な、プロセッサの構成と、それに必要なインターコネントと、メモリバンド幅がないと値は出ない。ピークFlopsをまともに出せるという観点ではそれなりの意味がある。
ピークFlopsが関係ないとなると、他に何をしましょうということになる。これは今のFSチームの人たちも、結局、ピークFlopsに対してどのぐらいの効率をアーキテクチャとして担保していくか。例えば、0.5B／Ｆとか、1B／Ｆみたいな話、あるいは、筑波大のグループでは、外に出るととんでもないが、中だったら4
B／Ｆ出てきて、インターコネクトはそこそこ、みんなそうだと。多分、はかれば、Linpackは立派な値が出てくると思います。筑波大のものはインターコネクトをしっかりすればという話ですが。
世界とLinpackで競争することが適当かどうかはともかくとして、Linpackの性能はもういいから、全然違う、例えば、FFTを持ってくるという話ですよね。
【牧野委員】今までサイエンスドリブンということをずっと言ってきており、それにもかかわらず、最終評価はLinpackですと言われたら、それは困る。だから、こういうサイエンスができると、そのサイエンスに対する計算能力であり、それはLinpackだけではなく、アプリケーションの実効性能を見ていく必要があると思う。
もう一つは、システムアーキテクト側からいうと、倍精度乗算で性能をはかるのはもう勘弁してほしいと思う。倍精度乗算ではかるのは電力消費が大き過ぎるので、単精度とかもっと低いところで十分なアプリケーションがいっぱいあるのに、非常に無駄な演算をして性能をはかっているというのは、これから電力が厳しいというときに、正しいやり方ではないと思う。
【小柳主査】Linpackについて過度にこだわるものではないが、多くの指標の一つとしてはそれなりに意味があり、Linpackがベースラインを示しているということもあると思う。
【秋山委員】Linpackが健康診断だとすると、とてつもなく変な肉体改造をして世界競争をしているわけで、私などから見ると、SIMDがどんどん深くなっていくのは困るし、いろいろなところを外したりして、ゆがんだ競争をしているということは認識してほしいと思う。
【中島委員】それは多分違って、Linpackの基本になっているのがDGEMMの性能ですが、今回の「京」のチューニングの中でもかなり活躍していて、今まで、マトリックス・ベクトル・マルチプライで直観的にはそうだったものが、マトリックス・マトリックス・マルチプライに置きかえることによって、これはキャッシュが当たるのでよい性能が出る。Linpackが頑張っているのは、結局そこです。もちろん、最後の10％とか15％はだれも考えたことがないような、パラレルブロードキャスティングのアルゴリズムとかあって、それは一般的に使えるとは限りませんけれど。
【秋山委員】この議論をするなら、何％のアプリケーションがそれを使っているか、それがどれだけの経済的な価値やサイエンスの価値を生んでいるかという勝負をすべきで、そういう評論家がいない。アーキテクチャの専門家とやっている間はトラディショナルだと先生方が信じていらっしゃるもので価値観をはかることになるので、そこに反対だと言っている。
【中島委員】理研のレポートによれば、20本ぐらいのアプリがあって、そのうちの6、7本だったか、8本だったかはDGEMMに置きかえることによって、これまでピークパフォーマンスが2％や3％だったものが、40％とか出るようになっている。
DGEMMが出ないマシンはあり得ないわけで、それはつくり方が間違っている。DGEMMの性能は、少なくともマシンの足腰の強さははかれる。健康診断をどういう意味でおっしゃっているのかはわかりませんが、29時間、そこそこの計算をやって、ぶん回して生き残るというのは別にLinpackでなくても、そんな計算はいくらでもあるわけですから、やればいいわけですけれども。
【平木教授】Linpackの議論で一番気になることは、結局、Linpackの性能をやると、効率志向という間違った方向に行くことである。アプリケーションの人が欲しいのは効率ではなく、同じお金でどれだけアプリケーションが進むのかということである。今の記述の中の在り方の中にコストという概念が何も入っていないというのは、そういった意味で間違った方向に振れる危険性があると思う。
Linpack効率が93％でも、コストが1割高かったら話にならないわけであり、そういうことをちゃんと読めるように書いてほしい。場合によっては、わざと性能を低めて、Linpack効率を上げるというケースもあるし、これはすごく微妙な問題だと思う。
【小柳主査】これは別にLinpackだけじゃなく、プログラムでも効率は下がったけれども、答えは早く出るという、Flopsは下がっても答えが速く出る場合もいろいろある。
【平木教授】そのときの絶対基準は何であるかといったら、1つは消費電力であり、1つはコストだと思う。ですから、そこは明確に、同じ消費電力、又はコスト当たりに問題を早く解決する、これが欲しいマシンなんだということを、もうちょっと明確化したほうがいいと思う。
【牧野委員】少し違う話ですが、3番の将来の我が国における計算科学技術システムの在り方という項目にリーディングマシンの必要性が入っているが、これが変だという気がしている。要するに、意見のところにも書いてあるし、参考のところにもあるが、リーディングマシンを開発することの意味は、スーパーコンピュータ開発をリードするシステムを開発するというところにあって、最先端のシステムを開発する、そのためには大きいシステムをつくらないと開発にならないということが一番大きいのではないかと思う。
それはシステムの在り方ではなくて開発の在り方として考えないと、Linpackの性能が1位という話が出てきてしまう。そこを考え直したほうがよく、大きい番号で言うと、リーディングシステムは3と4の間ぐらいに入ると思う。
【林計算科学技術推進室長】 リーディングマシンをここに入れている考え方としては、どのような能力のスパコンをどのように配置すべきか、我が国全体のスパコンの配置を考えたときにトップマシンは要るのか、要らないのか、全体がフラットの方がいいのか、山型になっていた方がいいのか、という意味でここに入れている。世界の最高水準のマシンがあったほうがいいとなったときに、それを開発するのか、調達するのかは次の議論になると思う。そもそも、そういうものが必要かどうかということを配置の中で議論をしてはどうかということである。
【小柳主査】この話は大体まとまりつつあるが、（2）のシステムの在り方、特に専用、汎用の議論をしておいたほうがいいと思うので、この点について、ご意見をお願いしたい。
【中島委員】専用という言葉には語弊があると思う。例えば、筑波大チームがやっているマシンは専用マシンではないはずで、ある特定のアプリケーション分野ではなく、ある特定の決まったカテゴリの計算の仕方に対してフィットしているマシンである。結果的に専用っぽいマシンを最終的なチョイスに入れた場合、我々は専用マシンをつくったんだというと、世の中に対して変なメッセージが出てくると思うので、専用マシンという言葉はなるべくやめてほしい。では、何にするかというのはノーアイデアで、「前衛マシン」とか言っている。
【牧野委員】そういう意味で「白書」のスライドに4類型というものがあるわけで、今の文脈で汎用と言っているものは、この絵で汎用というところに来ているものになるが、実は、結構専用になってしまっている。低い性能しか出ないアプリケーションも結構多い。その意味では、これは汎用で、これは専用という話ではなくて、向き、不向きが「京」やそれ以後の並列度が上がったマシンではどうしても起こる。
【村上委員】汎用、専用というくくりではなく、現在co-designをやっているわけなので、co-designをした結果を何と言ったらいいかになる。あるセットとしてのアプリケーションを念頭に置いて、それに合わせてシステムを開発しているので、それは汎用でもなければ専用でもないのかもしれない。co-designしたもので整備をしていくのか、市場にあるもので調達してシステムを整備していくのかというくくりの方が自然だと思う。
【小柳主査】この議論が出てきた一つの理由は、今の「京」の設計の初期に、専用システムを入れたシステムを考えたという歴史的な事情があって、最終的にはそれは採用されなかったが、それが背景にあるのではないかと思う。
【常行委員】専用という言葉はあまりいい印象がないかもしれないが、ユーザーが多く台数が多ければ、それはそれで大変意味のあることで、その観点でいうと、今回のHPCIの議論がどこまでの範囲を考えているのかが理解できていない。そこをはっきりさせたほうがいいと思う。
どこまでという意味は、リーディングマシンとその次のレベルの情報基盤センター等のレベルも書かれている。では、その下のレベルはどうなのか。例えば、今、政府調達のスーパーコンピュータの定義は1.5TFlopsというとんでもなく低いところに設定されていて、その意味でいうと、スパコンは各研究室に入ってもおかしくない。その状況でこのHPCIというのはどこまでの範囲を考えて議論していくのか。それから、学術的な意味で重要かどうかはもちろんですが、経済的にそれが今後、日本で開発していくことが成り立つのかどうかということも、頭に入れておかなければいけないと思う。どこまでの範囲を考えるのかというのは、重要な要件だと思う。
【平木教授】専用と汎用を分ける一番の問題は、コスト的にペイする規模がどこにあるかということで、専用はそれが少ないからこそ専用でつくることができる。コストというのはすごく大事であり、何ラックつくったらビジネスとして成り立つかという線が低いシステムと高いシステムがある。高いシステムは、当然、高いだけいろいろなことに使えなければいけないし、低いシステムはある特定なこと、サイエンスを進めればいいという概念で書いてほしいと思っていますが、牧野さん、いかがでしょうか。
【牧野委員】専用システムといっても、例えば、中島さんからあったように、DGEMM専用マシンというのは成り立つんです。
【中島委員】成り立たんでしょ。
【牧野委員】いや、アプリケーションの相当部分が、それだけが速ければいいというものは結構ある。そういう意味では成り立たなければならない。価格当たりのDGEMM性能が高いマシン、あるいは電力当たりのDGEMM性能が高いマシンというのは専用システムとしてあり得るわけです。
それは置いておいて、前回の検討の時点では、どちらかというとMD-GRAPEのようなものが想定されていたはずで、それをという文脈なのか、それとも今回のアプリケーション部会で出したような汎用の中でのバリエーションを考えているのかを、クリアにしていただくことが必要かと思う。
【小柳主査】汎用という言葉も大変誤解を招く言葉で、前回の「京」コンピュータのときは、最初のふれ込みが、汎用スパコンをつくるから、どんなアプリでも動くんだから、アプリについては考えなくていいと、極端に言うとそのような議論で始まったところがある。私や岩崎さんはそれを大批判して、具体的なアプリをターゲットにして設計しなければ、設計にならない、ということを言ったが、その意味で、汎用という言葉も非常に誤解を招く。
先ほど村上さんの指摘にもあったように、牧野さんの示したマップがある程度、この領域でいえば、ある意味で専用的な面もあるわけで、汎用にしても、専用にしても注意して扱わないと、間違ったメッセージをすることになると思う。
【加藤委員】今のに関連して、ペタまでは汎用という言葉はある程度妥当と思うが、エクサの時代には、多分、それはないと思う。それはアプリを調査・検討して、結局、ある程度はアプリの集団に合わせてマシンを開発しないといけないのは明確で、例えば、汎用といってもコスト的に見ると、あまり性能が高くないという。だから、どの性能を重視した、どういうマシンを開発すべきかという表現の方が妥当だと思う。
【小柳主査】前も特徴のあるマシンを複数とかいう言い方をしている。その意味で、この議論の構成をもう少し練り直す必要があると思う。
【中島委員】非常にパッシブな汎用の定義は、世の中で一番使われているタイプということになる。だとすると、今現在、x86クラスタが汎用になる。「京」はx86クラスタに対して大きく外れていない。もちろん「京」はx86ではないが、x86クラスタだとプログラマから見たときのビューがあまり変わらない。というのが、「京」の汎用の汎用たるゆえんであると。これが6年後、まだx86クラスタかという話はある。
【加藤委員】その延長でほんとうに成り立つのかというところは……。
【中島委員】成り立つか成り立たないかというのはある。要するに、世界中が、一番はx86クラスタじゃなくて、10番はx86クラスタだよねというのが今の状況である。それが10年後もx86である必要はないけれども、そこそこポピュラーな、そこそこの価格で手に入るようなプロセッサの、そこそこの集合体で、エクサが行くのかどうかというのはわからないが、仮に、デスクトップはみんな100％ですとなると、多分、それがなり立つ。
【小柳主査】それも確かにある意味で汎用ですが、スパコンのユーザーが汎用と聞くと、自分のプログラムが速く走るマシンが汎用だとみんな思うので、そういうところは間違った幻想を与えるような気がする。
【秋山委員】汎用と専用という言葉は語弊を生むので、別のラベルをつくらなければいけないが、外の世界にこの話を持っていったときに、何で2つもつくるんだ、どちらか一方でいいじゃないかとなる。数年前はベクトルかスカラかというところでそういう議論があった。だから、この2つが汎用型、専用型と同じぐらいに、新聞を読んだときに一般市民がわかる言葉を発明しないと、どちらか一方でいいじゃないかと言われてしまうのではないかと思う。
【加藤委員】結局、我々は2020年ごろに、この世界がどういうふうになっているか、まだ定量的に明確なビジョンがないような気がしている。例えば、「京」をつくって、その後継機は何台売れるかとか、これから、スパコンが私自身は何個かにタイプが分かれていくと思っているので、それぞれがどういうビジネス展開をされるかということも含めて、社会に説明する必要があると思う。
【宇川委員】その点もそうですし、技術的にどうなのかということも、本来はFSでやるはずなわけで、議論が空転しているような気がしないでもない。
ただ、汎用、専用という言葉がある種、それぞれの人がそれぞれイメージを持っていて、あまりいい言葉ではないというのは私も同感です。特に、専用というのが分野、あるいはアプリを限ってしまうシステムだというイメージが強く、一方でFSはそうではなくて、幅広いアプリに対して、それぞれのアーキテクチャはほんとうに行くのか、行かないのかということを検討している。だから、そこは大事な共通理解ではないかと思う。
【土居計画推進委員会主査】「FSは」という最後のくだりはそう考えていない。今後のスパコンとしてどうあるべきかを考えるに当たって、どこかに特徴を置いたものを主張されることがあってもよいということで進めていただいている。
【宇川委員】それはそうですが、アプリを特定しているわけではないということですね。
【土居計画推進委員会主査】アプリを特定しているわけではなく、例えば、富田さんのチームから出てきたものが、みんながみんな全部うまくかかるかは注文をつけていない。
【松尾委員】専用ということでちょっと気になったのが、今回、アメリカで速いものが開発されたということですけれども、あれはどこかの研究所でクローズして使うものですよね。
【小柳主査】セコイアは秘密の任務のためのマシンで、ただし、トップ10の4つぐらいは同型機ですし、もっと下にもそれの小さなものがたくさん、一般目的のために使われているという認識です。
【松尾委員】そういった意味だと、そういったコンピュータもどこかが使うという意味では専用ということになると思う。
【中島委員】Blue Gene／Qはどちらかというと汎用になると思う。
【小柳主査】Blue Geneは昔は専用と言って始まったが、結果的に今のBlue Gene／Qはどちらかというと汎用マシンという認識である。
今までの議論も大変有益な議論だったと思うが、今日はここまでにして、残りの部分については、引き続き議論を進めていきたいと思う。
村松計算科学技術推進室長補佐より、次回の日程（9月11日火曜日、17時から19時）を報告。
小柳主査より閉会発言
電話番号：03-6734-4275
メールアドレス：hpci-con@mext.go.jp