ここからサイトの主なメニューです
情報科学技術委員会 計算科学技術推進ワーキンググループ(第1回)議事録

1.日時: 平成16年8月20日(金曜日)15時〜17時

2.場所: 文部科学省ビル 10階10F1会議室

3.出席者
(委員) 石井委員、伊藤委員、宇佐見委員、大野委員、岡本委員、奥田委員、
泰地委員、根元委員、羽生委員、姫野委員、松尾委員、松岡(聡)委員、
松岡(浩)委員、村上委員、室井委員、諸星委員、矢川委員(主査)、渡邉委員
(科学官) 西尾科学官
(HPCベンダー)日立製作所、富士通、日本電気
(事務局) 文部科学省 研究振興局 情報課
星野情報科学技術研究企画官、當麻学術基盤整備室長、中里課長補佐

4. 議事
(1) HPCベンダーにおけるHPCハードウェア開発の動向について
1 日立製作所
2 富士通
3 日本電気
(2) 文部科学省におけるHPCハードウェア開発に向けた取り組みについて
(3) その他

5. 配付資料
資料1   計算科学技術推進ワーキンググループの設置について
資料2−1   将来の超高速計算機に必要な要素技術の研究開発について(日立製作所)
資料2−2   将来の超高速計算機に必要な要素技術の研究開発について(富士通)
資料2−3   将来の超高速計算機に必要な要素技術の研究開発について(日本電気)
資料3   文部科学省におけるHPCハードウェア開発に向けた取り組みについて

6. 議事
(1) 計算科学技術推進ワーキンググループの位置づけ
資料1に基づき、計算科学技術推進ワーキンググループの位置づけに関し、事務局より説明があった。
(2) HPCベンダーにおけるHPCハードウェア開発の動向について
1 資料2−1に基づき、日立製作所よりHPCハードウェア開発の動向について説明があった後、以下の質疑応答が行われた。(○:委員、●:ベンダー)

委員  ペタフロップスを実現するために当然ながら量の追及は必要。量だけでなく、質的な変化は、ひとつのブレークスルーかと思うが、どういったところが重要だと認識しているのか。

ベンダー  一番典型的な例である、(C)(超多演算機CPUベース)のアプローチは、アプリケーションに固有なアプローチになる。アプリケーションの構造、必要な演算の構造によって、CPUの構成が可変であるか否かという議論はあるが、(A)(超高速CPUベース)と(B)(超低電力CPUベース)に関しては、ハイエンドCPUを並べて如何に効率よく動かすかという従来の延長のアプローチである。(C)はご指摘のような違う発想で超高速計算機を実現するアプローチである。ただ、現時点でどのアプローチを取るべきか、アプリケーションの要求をよく分析しないとわからない。今後のワーキンググループでの検討に合わせていきたい。

委員  メモリに関してはどのように考えているのか。CPUはかなりアグレッシブな性能向上を描かれているが、メモリは全然速くなっていない。

ベンダー  発表の中では低レイテンシと紹介している。特に(C)の場合、メモリのアーキテクチャをどうすべきか、ということがいろいろ課題になってくると考えている。

委員  それは、(A)でも(B)でも同じことが言えるのでは。

ベンダー  はい。(C)のアプローチでは、ペタフロップスクラスということで、0.5ペタバイト位のメモリ量で、特殊品だと実現が難しい。汎用品をいかに効率よく使うかに着目して検討した。そのため、一部、高速伝送のものを変換チップを経由し周波数をさげるとか、そういった構造の検討をして、だいたいこのくらいの性能が達成できるということを検討した。

委員  その場合のメモリは、スタティックRAMか、またはダイナミックRAMか。

ベンダー  ダイナミックRAMである。


委員  超高速で低消費電力、それ以外無いと思うが、産業界も含め、今まで低消費電力に関して考えておらず、デバイスにしても何にしても、とにかく速くなれば良いということできたと思う。低消費電力だとコンセプトをかなり変えないといけない。これはベンダー3社に聞きたいが、5年間でブレークスルーすべき技術は、ものすごく高い壁があるような気がするが、見通しはあるのか。

ベンダー  今回、あまり詳しい内容に踏み込んで説明できなかったが、個々の必要な要素技術自体は、研究を進めているものも多い。これを如何に組みあわせてやるか。電力を下げるためには「超多演算機アーキテクチャ」では、速度の最適化が重要。クロックを速くする必要のない場合はクロックを下げて、電力を下げるといった、システムとして最適な電力消費量に抑える技術が大事。デバイスからソフトウェアまでの組合せで、アプリケーションからの知見が重要だと考えている。このレベルの検討で今回とどまっているが、バックグラウンドでは、もう少し詳しい検討を進めている。

委員  汎用性の高さに重きをおいているようだが、それと(C)とはどう両立するのか。

ベンダー  (C)は演算をある程度絞って、専用ハードを並べるということが主眼。ひとつの方法としては、構成を変えるような技術が非常に着目されており、そういったものを組合せれば、ある程度汎用の演算機を載せておいて、結合や組合せを変えて、場合に応じてアプリケーションに応じた専用のCPUに見せかけることが技術的に可能だと思っている。(C)のアプローチが汎用からかけ離れているわけではないと考えている。

委員  その場合は違う構造を持ったCPUを接続することになるが、接続する技術は?

ベンダー  動的にソフトウェア、マイクロコードでハード構造を変える技術が最近出てきている。それとの組みあわせで、汎用性と超多演算器の両立の可能性があるのではと考えている。


委員  ハードウェアの課題という項目があるが、2010年に達成すべき課題か。

ベンダー  2010年にペタフロップスクラスのシステム性能を実現するために必要な技術である。

委員  (A)の超高速CPUベースでは、マルチコアを考えると2007年くらいに、1CPUで数10ギガフロップスが達成できる。2007年頃、4コアができる。(B)の超低電力CPUベースでは、今の高速CPUで、2005年か2006年に5Wクラスで、1.5ギガヘルツ。0.65ナノメートルで2ギガヘルツ。CPUあたり5ワットで3、4ギガフロップスを達成可能。(C)の超多演算器CPUベースでは、倍精度か単精度かということはあるが、コマーシャルマイクロプロセッサで2010年の2年くらい前に達成すると思うが。

ベンダー  確かにここの数値だけでは、そういったことに見えるが、大きな目標としては、高い効率の達成を考えている。高い効率の達成に向けて、(B)の中で通常の単純な低消費電力ではなく、さらに効率30パーセント〜50パーセントにあげるために物量を追加するといったイメージで検討している。

委員 具体的にはどういう技術か。

ベンダー  (B)の中でレジスターを増やすとか、メモリアクセスのためのバッファを増やすことを検討した。面積がこの位になることを想定して消費電力を出している。

委員  ピンバンド幅がどのくらいに増えるか。今後マルチコアになっていく段階で、どこでハードウェアがネックになるか。ピンあたりの信号がネックになってくるとすると、内部バッファよりは、コアあたりのメモリアクセスが有利になってくる。単一プロセッサでメモリバッファを大きくすることにより、マルチコア部分で、小さいハードウェアでレイテンシは大きく、スレッド単位になっていく。CMP(チップ・マルチ・プロセッシング:デュアルコア、マルチコア)になっていく技術的な動向になると思うが。

ベンダー  プロセッサに着目するとCMPのアプローチは理解できるが、1箇所にプロセッサが複数ある形では、実装構造まで検討すると作りにくい。このため、マルチコアといったアプローチでやるよりもバラバラな形につくらないとかなり苦しいので、このようなアプローチで検討している。

委員  IBMはDIMMよりちょっと大きい。今、デュアルコア。2007年に4コアで出してくるのでは。もっと大きいバンド幅になる。

ベンダー  マルチコアは、2コア、1コアといった精度では、いろいろパラメータを作れる。8コアとか、そういったプロセッサも含め、(B)のアプローチを選択してしまうと、メモリバンド幅の確保と構造上の事まで検討すると難しい。

2資料2−2に基づき、富士通よりHPCハードウェア開発の動向について説明があった後、以下の質疑応答が行われた。(○:委員、●:ベンダー)

委員  SIMDは、ベクトルを前提としているのか。

ベンダー  ベクトル的な演算を意識している。


委員  ペタフロップス達成のための質的変化や課題は何か。

ベンダー  ひとつは、従来の延長ではうまくいかない。発想を変える必要がある。インターコネクトの光をどう扱うか、バランスをどう取るか。もうひとつは、アプリケーションドリブンでないといけない。テクノロジーはアプリケーションによって支持を受ける。特にハイエンドはそういうふうに色分けされる。


委員  メモリに関し、4ギガビットのDRAMを使うと、チャネル数を確保できない。ずっと小さいDRAMを使うと、数が膨大になり、かつ消費電力が膨大になる。ベクトルだともっとひどくなる。メモリでマシンが死んでしまう。そのあたり、どういうふうな解決策は考えているのか。CPUは速くできるが、メモリが実装上無理では。

ベンダー  ご指摘の通り。アプリケーションの作り方を含めて工夫が必要。

委員  メモリバンド幅を下げれば、高集積チップを使えるし、容量を確保できる。バンド幅を確保しようとすると、チップ数が増え、さらには消費電力が増え、マシンが作れないのでは。

ベンダー  ご指摘の通りだが、今は整理できておらず回答できない。検討させていただきたい。


委員  特にハイエンドの部分でアプリケーションオリエンテッドがいいとおっしゃっていると思うが、ブレークスルーを起こそうとしたら、アプリケーションをどこに使うか、明確にしていないと、生半可にはできない。その技術を汎用に使えるものとして、構築できると考えてよいか。

ベンダー  同じことを申し上げたつもり。特殊なものではなく、極力、汎用的なもの、一般性のあるものがターゲットをクリアするようなアプローチが成功する鍵だと考える。

委員  ペタスケールコンピューティングが拓く世界というスライドでは、数値計算、大規模計算、検索等があって、CPUは均質なシステムだが、実際にはヘテロなシステムが良いと思うが、如何。

ベンダー  本日説明したのは、計算系である。汎用的な、もう少し視野を広げた検討が必要。われわれも検討を始めたところである。

3資料2−3に基づき、日本電気よりHPCハードウェア開発の動向について説明があった後、以下の質疑応答が行われた。(○:委員、●:ベンダー)


委員  8枚目のスライドに関し、ベクトルのレジスタサイズも有限のサイズがあると思うが、キャッシュサイズと同じように限界があるのでは。

ベンダー  ベクトルレジスタのサイズはあまり影響しない。一番影響するのはバンド幅である。

委員  ベクトルはメモリのバンド幅が直接見えるタイプになると思うが、ベクトルとスカラで同じメモリバンド幅を仮定した場合は、このようなカーブに本当になるのか。

ベンダー  同じバンド幅なら、命令の並列度が演算を隠蔽する場合、スカラの場合、命令フェッチからインデキシングをやり、分岐等のオーバヘッドがある。ベクトルは一旦、命令を持ってくるとあとは演算なのでオーバヘッドが少ない。スカラは、キャッシュ固有の演算をどれだけ減らせるかが性能に影響する。

委員  バンド幅に直接依存するようなアーキテクチャの場合、バンド幅はどうやって稼ぐのか。

ベンダー  これが実現できれば、地球シミュレータ程度のものが出来る。そのためにはこういったパラメータが実現できる必要がある。

委員  インターコネクトも問題だが、メモリそのものも問題。高速のレイテンシが実現できる要素技術はどういったものが可能か。

ベンダー  今の延長の技術で出来ると思う。このテクノロジーが出来るとすれば、容量とコストの関係になり、コストとのトレードオフになる。

委員  なぜ、トレードオフか。汎用DRAM品で、例えばサーバに使われるようなメモリの1チャンネルあたりのバンド幅は、10数ギガバイト毎秒。400ギガバイト毎秒なら20数倍必要になり、特殊品になるのか。

ベンダー  今、現在、製品では無いが、先日エルピーダメモリ社から144メガビット、ランダムアクセス5,6ナノセコンドが発表された。

委員  DRAM単体の問題だけでなく、どのくらいビット幅のインタフェースがあるかに依存するのでは。汎用RAMで一番コストが高い部分はグラフィックスカードの部分、組込み用の部品、汎用PCの部品の3つのマーケットにフォーカスしているが、適切な製品が2010年のロードマップで出てくるのか。

ベンダー  ある程度特殊だと思う。地球シミュレータも汎用なDRAMでは無く、特殊品を使った。

委員  そのときにチップの個数は十分抑えられるのか。

ベンダー  2010年にどうなるかは、わからない。

委員  汎用のDRAMは使いにくくなるのでは。


委員  アプリケーションドリブンという話がでたが、アプリケーション側から何か質問は。

委員  メモリに対するデータがどんどん提供されるアプリケーションとか、それが決まらないことにはハードが決まらないということは良くわかる。逆にペタフロップスを出すアプリケーションは、こういうアプリケーションだったら2010年には簡単にできるとか、あるいは、こういうアプリケーションだったら2010年までにペタフロップスのアプリケーションができないとか、何でもかんでもペタフロップスが出せるとも思えない。その辺の制約条件はどうか。メモリを使わずにデータがどんどんくるものはペタフロップス値があがると思うが、有限要素法のように、参照データがやたらと多いものだとどうか。

ベンダー  メモリのインタラクションが多いようなアプリケーションは非常に難しい。インタラクションが大きくても、ローカライズされれば性能が出やすいわけだが、現在のアプリケーションでどういうことになるのか、一言ではいえない。まったくアーキテクチャに合わせてアプリケーションを考えることもあるが、それはアプリケーションを限定してしまうような気がする。そういうことが良いといえるかどうか。

委員  ある程度分類できるのではないかと思う。構造格子のデータを使う場合、たとえばランダム系の粒子系を分けた場合、ある程度アプリケーションの類型を分けたうえで、ハードウェア的な可能性を検討する余地があるのか。

委員  この議論に対する他の2つのベンダーの意見は。

ベンダー  アプリケーションのタイプで、粒子系なのか流体系なのかということで、どのくらいのメモリ容量が必要で、ノードにすればどのくらいでとか、ある程度のパターン化は可能だと思う。パターン化をした上で、そのアプリケーションを最初に選んで、アーキテクチャを絞るという作業をし、最終的にどういうマシンで、コスト評価に照らし合わせてどうか等、現在は分析できていないが、その作業はアプリケーション専門の方の意見を聞きながら進めていくべきだと考えている。アプリケーションの分野だけではなく、実際の性能評価を進めていくとなると、1プロセッサあたりにどの位のデータが載るかとか、具体的な数字を用いないと、そのときにキャッシュメモリがどのように効くのか、メモリバンド幅の実負荷がどうなるかが決まってこない。相当、具体的なところで詰めさせてもらわないとアーキテクチャが決まってこないと思う。今後、こういう話が進んでいくのであれば、そういったレベルの議論をする機会があれば良いと思う。

ベンダー  SIMD型のマシンを想定して、カーパリネロ法の実コードを見ながらどの位の性能が出るのかを分析した。インターコネクタの性能は思ったよりいらなかったとか、そういうことがわかってきた。実効性能で700テラフロップスくらいでる。そういう分析ができてくるのではないかと思う。いろいろなアプリケーションでやらないとまずいと思う。単純に並べて計算が速くできるようなら、非常に簡単できるが、設置面積とか、電力を考えると、ただクラスタを並べるだけではまずいということもあるので、高密度実装や低消費電力はアプリケーションに関係なく必要な技術だと思う。一番最初のフェーズだと実効性能で1.9ペタフロップス、次のフェーズだと0.4ペタフロップスとか、これはあるアプリケーションに限って調べた例だが、想定したほどインターコネクトの性能が要らないと言う事もわかってきている。これは、できてしまうことを保証しているわけではなく、あくまでも検討結果ということである。

ベンダー  もうひとつ大事なことと考えているのは、全部のアルゴリズムがそうではないが、収束計算をさせるタイプのアルゴリズムである。ペタフロップスが高いからといって、収束性が高いかというと必ずしもそうではなく、実際の計算を速くさせる目的においては、収束の速さとフロップスを両方考えないと実用的にはならないと思う。ここも実際のアプリケーションサイドとハードウェアサイドの協議がこれから特に必要な分野だと思う。


委員  アプリケーションに関して、2010年でペタフロップスが必要なアプリケーション、非常に大規模な計算を考えた時に、ただひとつの方程式を、ただひとつのやり方で解くということは、かなり想定しにくく、マルチレベルの非常にミクロなナノからマクロのスケールまでを階層的に扱ったり、マルチフィジックスでいくつかの方程式を連立させて解くようなタイプのほうが想定としては自然だと思う。これを全部解くための単一のアーキテクチャを提案することが本当に良いのか疑問だ。ノード間のインターコネクトを共通にして、ノード毎に特徴を持たせたヘテロなシステムというような提案や計画があっても良いのではないかと思うが、そのような観点は如何か。

ベンダー  おっしゃる通り。どういうインタフェースで、どういうターゲット性能で、どういうマシンがつながるかを想定し、どこまで共通にするかを詰めていけば、日本オリジナルのハイパフォーマンスのインターコネクトにいろいろなものがつながるという考え方もできる。ベンダーから見るとドライバや、内部バスを直結するものを作らないといけないが、そこが標準になればメリットが出てくる。

委員  それは、カスタム化という話かと思うが、ブレークスルーのひとつとしてカスタム化があると思う。ベクトルも、配列というデータ構造に着目して出てきたブレークスルーであり、ベクトルレジスタがあってベクトル処理をする。カスタム化はかなりコストを伴うもので、これによって、ブレークスルーで新しく出てきた技術をビジネスとして回収できるか。成り立たなければどんないい技術でも製品に活かされないと思うが。

ベンダー  ビジネスに結びつかないもの、非常に市場限定したものでは開発できない。開発したものはビジネスとして回収できる様に製品適用することが基本姿勢である。


委員  マクロからミクロまで全体を解くということが大事である。マクロは流体的なのでベクトル。ミクロは粒子的なのでスカラである。その間を結ぶという話だが、ものすごく高速で、全部が1対1でつながる必要があるとの意見もあるが、実はマクロとミクロの階層の物理の間は、そんなにたくさんの情報がやり取りされるわけではない。したがって、すごいコネクション技術をもってこなくても大丈夫である。汎用のベクトルマシン、汎用のスカラマシンをつなげるだけでよく、あえてカスタム化する必要はないと思う。

委員  ヘテロジニアスなもので特定の問題に向いたものが必要という話だったと思ったが。

委員  ノードごとに特徴を持ち、それぞれはカスタマイズされていないマシンをインターコネクトでつないで、全体としてヘテロにするアプローチがあるのでは。

委員  ノードはカスタム化されていなくて良いのか。特長はどういうふうに出すのか。

委員  既に3ベンダー別々のアプローチの説明があった。完全にバラバラなものの択一を迫っているかのように見えたが、そうではなくて、それぞれのいい所を組合せてもいいはずである。


委員  各ベンダーより、アプリケーションについて同じような表で表現されているが、実務のところでは、最先端のHPCは非常にドロドロしたことで困っていることがたくさんある。例えば、書類の検索は結構大変で、最近だとインターネットで良い検索エンジンが出回っているが、ああいったものがHPCにも欲しい。計算した結果をビジュアル化する良い物がないかとも考えている。残念ながら、各ベンダーとも、資料に1、2行しか記載がない。そのあたりの話も聞けるとありがたい。

ベンダー  アプリケーションに関しては個別技術ということで、アーキテクチャに近い技術の話をしたが、今おっしゃったように、そういう技術をどこに使うかというところにきている。ヘテロなアーキテクチャという話もあったが、企業の立場からすると、うまくバランスを見つけていかないといけない。

(3)文部科学省におけるHPCハードウェア開発に向けた取り組みについて
 資料3に基づき、文部科学省におけるHPCハードウェア開発に向けた取り組みについて事務局より説明があった後、以下の議論が行われた。(○:委員、●:ベンダー、△:事務局)


委員  事務局より説明のあった方針で、是非進めてほしい。私は利用者の方にマシンをお使い頂く立場であるが、4年毎にスーパーコンピュータを入れ替えており、この分野で米国を凌駕している。わが国の科学技術の中では、世界に胸を張って頑張れる一分野かもしれない。世界で最先端をいっている分野はキープしていく対応が必要である。いつ離されるかわからないが、絶えずやっておかないと、突然のブレークスルーは無いはず。この資料に沿って、実現に向けて、次の世代に何か残せるようになっていけばよいと強く思う。


委員  事務局に伺った方がよいのか、ベンダーに伺った方がよいのかわからないが、スカラにいくのか、ベクトルでいくのか、ユーザとしてはわからない。ベンダーから、いろいろなブレークスルーを提案され、共通の部分もあるし個別の部分もあったが、文部科学省としてはベクトルもスカラも両睨みで基礎的なところを取り組むのか。共有できるものを重視するということか。または、民間企業に任せるのか。

事務局  文部科学省の立場としては、特定の計算機アーキテクチャのみがスーパコンピュータとして残れば良いとは考えていない。したがって、端的に言うと両睨みで考えている。


委員  米国で動いているプログラムとしてHPCSがあり、2010年に実効性能が1ペタフロップスと言っている。米国でHPCSの状況を聞いたが、日本は負けそうとの危機感をもっている。ベンダーや文部科学省に伺いたいが、HPCSはもっとアグレッシブなことを言っている。何百ギガバイト毎秒のメモリは難しいので、インメモリの演算器などを考えている様だが、彼らに対する勝算はどういうところに有るのか。地球シミュレータでは勝ったわけだが、HPCSに勝てるのはどういう所か。プレゼンした内容がそうなのか、または、プラスαが必要なのか。

ベンダー  HPCSの各社の提案は良く調べてみないとわからないが、クレイのカスケードというマシンは、PIM(Processor in Memory)を使ったものである。ソフトウェアの作りやすさ等、いろいろな事を考える必要がある。日本で考えたときに、今でこそMPIで地球シミュレータにいろいろなプログラムがのっているが、まったく新しいソフトを作るには、すごく労力が必要だと思う。私自身は従来の延長で出来るのなら、それがベストではないかと思う。今回説明した要素技術が実現できるとしたら、かなりのものが米国、HPCSに十分対抗できるものができるのではないかと思う。


事務局  是非、諸外国のベンチマーキングをしたいと思っている。次回はインテルからもプレゼンをして頂く。

以上

(研究振興局情報課)

ページの先頭へ   文部科学省ホームページのトップへ