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

1. 日時: 平成17年6月3日(金曜日)14時〜17時10分

2. 場所: 文部科学省10階10F3会議室

3. 出席者
(委員)   石井委員、伊藤委員、宇佐見委員、岡本委員、奥田委員、下條委員、泰地委員、根元委員、羽生委員、姫野委員、松岡(聡)委員、松岡(浩)委員、室井委員、矢川委員(主査)、横川委員、渡邉委員
ゲストスピーカー   竹内 郁雄様(東京大学大学院 情報理工学系研究科 創造情報学専攻 教授)
(事務局)  文部科学省研究振興局   清水局長、小田審議官
  情報課  松川情報課長、星野情報科学技術研究企画官

4. 議事  
 
(1) 将来(2010年前後を想定)の研究目標とスーパーコンピューティング環境について
<説明者>竹内 郁雄様(東京大学大学院 情報理工学系研究科 創造情報学専攻 教授)
(2) ペタフロップス超級スーパーコンピューティングのグランドチャレンジとなるアプリケーションと必要とされるシステムの要件について
(3) ペタフロップス超級スーパーコンピューティングシステムを実現するオペレーティングシステムやデータベース技術などのブレークスルーについて
(4) ペタフロップス超級スーパーコンピューティングシステム開発計画(案)
(5) 計算科学技術推進ワーキンググループ第2次中間報告骨子(案)について
(6) 地球シミュレータの成果および運用に関する最新の状況について
<説明者>渡邉委員(海洋研究開発機構 横浜研究所 地球シミュレータセンター領域長)
(7) その他

5. 配付資料
資料1   計算科学技術推進ワーキンググループ(第8回)議事概要(案)
資料2−1   アプリケーションとシステム要件対応表(姫野委員 理化学研究所 情報基盤センター長)
資料2−2   アプリケーションとシステム要件対応表
(松岡(浩)委員 日本原子力研究所 計算科学技術推進センター 次長)
資料2−3   アプリケーションとシステム要件対応表
(渡邉委員 海洋研究開発機構 横浜研究所 地球シミュレータセンター領域長)
資料2−4   アプリケーションとシステム要件対応表
(諸星委員 防災科学技術研究所 防災基盤科学技術研究部門 主任研究員)
資料2−5   アプリケーションとシステム要件対応表
(横川委員 産業技術総合研究所グリッド研究センター科学技術基盤チーム長兼 副研究センター長)
資料2−6   アプリケーションとシステム要件対応表(中野委員 国立医薬品食品衛生研究所主任研究官)
資料2−7   アプリケーションとシステム要件対応表
(大野委員 物質・材料研究機構 計算材料科学研究センター 副センター長)
資料3   ペタフロップス超級スーパーコンピューティングシステムで必要とされる基本ソフトウェア、周辺システム等に関する検討項目
資料4−1   国家基幹技術としての世界最高性能のスーパーコンピュータの開発(案)
資料4−2   ナショナル・リーダーシップ・スパコン(NLS)とナショナルインフラストラクチャ・スパコン(NIS)の変遷
資料4−3   ペタフロップス超級スーパーコンピュータ開発計画の検討
資料5   計算科学技術推進ワーキンググループ第2次中間報告骨子(案)
資料6   地球シミュレータの最新の状況とペタフロップス超級スーパーコンピュータ開発プロジェクトへの提言
(渡邉委員 海洋研究開発機構 横浜研究所 地球シミュレータセンター領域長)
資料7   将来(2010年前後を想定)の研究目標とスーパーコンピューティング環境について
(竹内 郁雄様 東京大学大学院 情報理工学系研究科 創造情報学専攻教授)

6. 議事概要
  (1) 将来(2010年前後を想定)の研究目標とスーパーコンピューティング環境について
   
資料7にもとづき、竹内 郁雄様から説明を行った後、以下の質疑応答が行われた。
(○:竹内様、●:委員、△:事務局)

   
委員 エージェントモデルを10万規模用意する技術は何か。

竹内様 仮説でステレオタイプを用意して、そこから確率分布で振って作成している。

委員 モデルの確定後、ある程度のエージェントの数を用意すれば概ね動きが予測できるのではないか。

竹内様 数が多い場合の動きを予測することは困難である。

委員 複数プロセッサ用に並列化しても,処理の間のインタラクションが大きいのではないか。

竹内様 1台のマシンだとシミュレーションが非常に楽。巨大なアドレス空間を持つ共有メモリとして見えると良い。

事務局 地球シミュレータは環境の変化に力をいれたが、次は分野を特定しない。安全・安心な社会に向け、リアルタイムな意思決定システムとして需要があるように思う。2010年以降、自治体に使ってもらえる絵が描けそうか。ペタフロップス超級スーパーコンピュータの大きな利用分野になりうるのか。

竹内様 スーパーコンピュータで防災をやっても、自治体はそうは買えない。安全・安心だけでなく,「便利」が加わることでマーケットが広がるのではないか。市場を広げる努力が必要である。

  (2) ペタフロップス超級スーパーコンピューティングのグランドチャレンジとなるアプリケーションと必要とされるシステムの要件について
資料2−1(姫野委員)、資料2−2(松岡(浩)委員)、資料2−3(渡邉委員)、資料2−5(横川委員)に基づき、委員から説明を行った後、以下の質疑応答が行われた。
資料2−4(諸星委員)、資料2−6(中野委員)、資料2−7(大野委員)は、資料提示のみ行った。
(○:説明委員、●:委員、△:事務局)

   
委員 横川委員説明のアルゴリズムにはベクトル型が合致しているということか。

説明委員 スペクトル法なのでベクトルが得意である。ネットワークの負荷も大きい。

委員 ネットワークのバンド幅は、ベクトル・スカラと別議論である。

委員 姫野委員説明の中の必要マシン要件で、8〜16CPU程度を共有メモリにしている理由は何か?

説明委員 アプリケーションプログラムを作成する立場では、共有メモリに見えるメモリ容量がある程度必要である。
CPU数より共有メモリサイズが重要である。ここからバランスのとれるCPU数が決まる。

委員 いろいろなアルゴリズムでは、スキャッタ、ギャザーなどはスケーラビリティが問題になるが、MPIを使用し、領域分割した後でも、各ノードで何ギガバイトも必要という主張が理解できない。

説明委員 並列化できない部分があるため。cc-NUMAでも良い。

委員 メッシュを細かくする,空間を大きく取れるとの前提であるが、細かくすると物理モデルが破綻するなど頭打ちが出る。第一原理は良いが、他は限界が出るはずである。

説明委員 0.1mmくらいなら問題ない。マルチスケールなら、問題が出る部分はマクロに見るので良いはずである。

委員 0.1mmとするとネジ穴の問題が見え始めたりする。表面の粗さが問題にもなる危険があるはずである。

説明委員 どこまで入れるかは、例えばプラグケーブルはシミュレーションの対象から外すなど、必要な要素は取込み、不要なものを対象外とすれば解決できる。

説明委員 地球シミュレータの自動車応用に当初3ヶ月予定だったが6ヶ月かかったが、時間が掛かった理由は並列化が困難だったことと、メッシュが細かくなって、一つの部品がメッシュの何点かに跨るようになり、モデル化が破綻したことが原因である。

委員 ネットワークのバンド幅に加えて、ネットワークのトポロジがアプリケーション性能には重要な要素である。地球シミュレータにおいて、FFTの場合には、ネットワークのトポロジは1段接続であったことが、遠く離れた通信に関しても有効であったはずである。RedStormなどに採用されている隣接通信方式では、遠くはなれた通信にはあまり有効ではない。

  (3) ペタフロップス超級スーパーコンピューティングシステムで必要とされる基本ソフトウェア、周辺システム等に関する検討項目について
   
資料3に基づき、矢川主査から説明を行った後、以下の通り質疑応答が行われた。
(○:矢川主査、●:委員、△:事務局)

   
委員 グリッドに関して国際性を考えると、欧米ではインフラとして取組みが進んでいるので、国際的な互換性の確保が重要であるので検討して欲しい。また、IPストレージによる高速データ転送に関して技術的意味がよくわからないので教えて欲しい。IPストレージはiSCSI等を使うので遅くなる。数百ギガバイト毎秒〜1テラバイト毎秒くらいの対応速度が必要であると思う。ASCパープルでも130ギガバイト毎秒位である。10倍のスケールでも1テラバイト毎秒である。

矢川主査 グリッドの国際性に関してはNARERGIでやっているのではないか。

委員 各国、全く同じソフトウェアスタックであることは難しいが、認証やジョブの表現方法など、今後、互換性を保証していくという方向性である。ペタフロップス級スパコンでは、よりセキュリティを厳しくする必要があるのではないか。DOEでは、NSFと同じソフトウェアスタックを使用していても、よりセキュアである。

事務局 グリッドなどの国際的な互換性の確保については、委員のご発言に同意する。IPストレージについては、トップの高速化の実現ではなく、IPストレージのようなものでも、少しでも高速性について、検討した方が良いのではないかという意味である。

委員 この10数年で、主記憶容量は1,000倍程度に増加したが、ディスクへの書込み速度は、ユーザから見て10倍程度しか向上していないのでないか。この先、この差はますます広がり、計算は終わっても、なかなか結果が出てこなくなるのではないか。

委員 並列にすればよいのではないか。

委員 並列化をたくさん行うとすると管理が大変なのではないか。

委員 それはデータ量の問題である。ASCパープルは100TFのマシンがもうすぐでるが、I/Oについては、130ギガバイト毎秒のリード/ライトが要求であり、これは高いほうであると思う。単純に1ペタフロップスにスケールするとファイルのI/O速度は1テラバイト毎秒が必要で有ると思う。ASCでも400ギガバイトのスピンドルでは速度が向上しないので、250ギガバイトのスピンドルにして並列化したと聞いている。将来、1テラバイト毎秒は出来るのではないかと思う。

委員 地球シミュレータもローカルI/Oにして、ノード数分の並列化をしているのではないか。

委員 そうである。

委員 現在の技術では、10,000スピンドルで、1,000ストレージコントローラで1テラバイト毎秒を実現しなくてはならない。ソフトウェアスタックが変わるので、技術的に変えなくてはいけないという点では同じである。

委員 可視化のところで、能動的可視化とは、何か?

事務局 計算結果の抽出方法として、大規模なデータの可視化手法を自動的に選択する等効率化を図るようにするという意味である。

委員 全体アーキテクチャとは、どのような関係になるのか。

事務局 大規模データであるが故、可視化の課題を解決する方法論の一つとしてどうか、との意味である。

委員 計算資源の仮想化とはどういったイメージなのか。

事務局 グリッド技術との関係で考えていて、ペタスケールのひとつのコンピュータのみではなく、グリッドでつながれている、遠隔での計算機資源がバラバラなイメージにさせない。グリッドとの親和性を考えたスーパーコンピュータシステムを考えていくべきであるとの思想に基づく表現である。

矢川主査 ユーザから意識しなくても良いという事か?

委員 そうである。

委員 ソフトウェア開発は長く時間が掛かるし、熟成していくことも必要である。ハードウェアは5年しかもたないが、ソフトウェアは数10年もつ場合がある。その資産を有効に使うことが重要であるが、資料3にはそのような記述がないので考慮するべきである。

事務局 了解。

委員 Co-Array Fortran(CAF)は、本当に対応するべきものなのか。それは何故なのか。

委員 CAFはマルチノードの環境下において、MPIでスケーラブルかつ性能の良いプログラムが作れる、米国ではデファクトになるかもしれないので入ったのだろう。UPCもひょっとしたらデファクトになるかもしれないので、ここに記載があるのではないか。直接メモリ間転送ができるプログラムが作成できる。

事務局 検討するべき項目を列挙しただけであり、対応をしなければならないということではない。今後、先に意見の出た国際性や技術的な観点などで検討していくべきであると思う。本資料では可能性のあるものをなるべく列挙している。

委員 CAFは計算機のアーキテクチャにかなり依存するので、互換性のために有効とは思えない。

  (4) ペタフロップス超級スーパーコンピューティングシステム開発計画(案)について
   
資料4−1、4−2、4−3に基づき、事務局から説明を行ったのち、以下の通り質疑応答が行われた。
(●:委員、△:事務局)

   
委員 データベースとの連携など数値計算には向かないようなアプリケーションもあると思うが、その代表として、Grape-8を記載しているのか。

事務局 専用用途部分の代表として、Grape-8と記載している。但し、ひとつのものさしに過ぎないが、TOP500でトップを取るために必要という認識もあり、その期待を寄せているのがGrape-8である。データベースエンジンは視野の外である。

委員 2005年5月に東大SR11000が16TFというのは間違いであり、5.3テラフロップスである。

事務局 訂正する。

委員 スカラ型を一括りにしているが、スカラと言ってもバリエーションがある。SMPの巨大なメモリが必要な人もあれば、PCクラスタ的なものが必要な人もある。

事務局 詳細は未検討である。スカラ型など、一括りで考えているが、詳細は今後の設計活動で考えるべきである。各々のアプリケーションで必要な要件を見据えて、今後設計していく必要があろう。

委員 ヘテロ構成にグリッド技術は有効だが、世の中にはいろいろなアーキテクチャがあるので、百貨店的にどのようなモデルを考えるのか?

事務局 留意して考える。

委員 ベクトル計算機とGrapeは国産だが、スカラは米国製に独占されている。米国内のスパコンの顧客は米国製に限定しているし、米国以外には使わせない。国産技術を育てていくのか。

事務局 過去の経験と今の情勢から考える必要がある。地球シミュレータ開発でも、開発ものではあったが、米国のスーパー301条との絡みで海外にも門戸を開いて総合評価で当事者をきめた。国内産業育成という視点で米国を排除できるとは考えていない。

委員 排除という意味ではなく、スカラ型を開発するのかという意味である。

事務局 産業育成というのみの視点で、次世代のスパコンの設計仕様を考えている訳ではなく、このようなものが必要なので、このような設計仕様で調達を募集するということで、その中に日本の強みを活かした設計仕様も当然、ありえると思う。

委員 トータルとして、ペタフロップスを実現するのか。

事務局 そうである。単一のものさしで、ひとつのシステムとして世の中に公表されているので、そこに対して世界最高になることが、国のリーダシップ・スーパーコンピュータの役割であることで、トータルで考えている。その際に、専用機、スカラ型、ベクトル型各々の国際的なトレンドをふまえて考えるべきであろうと思っている。

委員 トータルでペタフロップスの実現では、全部、同時に使える人は誰もいないのではないか。殆どのユーザは、このシステムのごく一部を使うことになるのではないか。そうなると、ペタフロップス級としての計算機の魅力がない。従来の計算機システムやグリッドとの棲み分けも問題であり、この辺はどのように考えるのか。

事務局 トータルで1ペタフロップスではない。トータルすると、すごく大きな性能になると思う。

委員 マシンアーキテクチャとソフトウェアの点から考えると、全然違う箱をつなげることは、グリッド的にはうれしいが、一方、資金は限られているので、産業育成の観点から考えると、どこを共通化できるかを考える必要がある。ネットワークやメモリシステムは共通化できる。各社いろいろと製品のラインアップに戦略があると思うが、ナショナル・リーダシップのスーパーコンピュータとするのであれば、キャパシティを大きくしたいのであれば、なるべく共通技術を採用して、メモリを共通化してスカラでも高いメモリバンド幅を得られるとか、ベクタでもスカラに切替時にはすぐできるとか、Grape-8もバンド幅をより広げるとか、データセットをすぐアクセスできるとかソフトトウェアも共通化するとか、全然違う箱が3つ並んでいて、どれもそれぞれ、ちょっとずつしか使っているという事態が起きないような施策を考えるべきであると思うがいかがか。

事務局 ご指摘の通りである。技術の共通化を視野に入れて考えていくのが、ITの分野におけるスーパーコンピュータ技術としての大きな役割であると考える。

事務局 異なるいくつかのアーキテクチャをつなげる複合型の場合、技術を標準化していくことは大事であるが、一方、個々のアーキテクチャの性能を最大限に引き出すことが一番重要である。基準を決めたがために、性能が将来にわたって出しにくくなる基準をきめてしまうと、日本の強みを活かせなくなることも考えられる。したがって、あまり数値的な基準をきめてしまうと後々問題になるのではないか。そこは、設計時の要のひとつであると考える。

委員 複合的なシステムにおける目標性能をどう考えるか。すなわち、目標性能を考えるべきであるが、これらのシステムを使うアプリケーションを見つけるのか、LINPACKで最高性能を目指すのかは、開発前に決めておいた方が良いと思う。ハードウェア側だけではなく、むしろアプリケーション側の覚悟が必要である。

事務局 今のご指摘を見極めるためにも、本日のアプリケーション分野の先生方からのご提案をして頂いているわけだが、今回のアプリケーションの検討結果などから検討が必要である。このプロジェクトが大々的に紹介される時には、その辺を今後、きちんと判断をしてすすめなくてはいけない。

委員 ベクトル計算機とスカラ計算機が並んでいるのは違和感がある。スカラ計算機は共有メモリ型、PCクラスタ型でトレンドが異なる。世の中のトレンドとアンマッチしていないか。ほんとにベクトル計算機部、スカラ計算機部というわけ方なのかは疑問である。

委員 その辺はこれから詳しく議論がされることではないかと思う。ベクトル、スカラ型独立で使うのではなく、これから5年10年先はマルチスケール、マルチフィジックスとなる時代になる。設計段階では微細になっていく。

事務局 事務局の方で、大学や研究機関でのスーパーコンピュータ所有状況の調査では、共有メモリ型か分散かは区別して把握している。その区別をしないで、今後、議論を進めるつもりは無い。現段階に於いて、そこまで細かいことを示したうえで、概念図を出す意味あいを感じなかったので、スカラ型一括りにしたが、その点がご不興ということであれば、考えていきたい。両方使うのか、どちらかだけを使うのかなどの議論が十分進んでいないので、そのような段階で、内訳まで記載してしまうと、今後検討が必要である。大きな概念として示す上で、そこまで細かく記述しなくても良いと事務局は判断した。

  (5) 計算科学技術推進ワーキンググループ第2次中間報告骨子(案)について
   
資料5に基づき、事務局から説明を行った後、以下の通り質疑応答が行われた。

   
委員 纏めかたはこれで良いと思う。地球シミュレータはひとつのケーススタディであった。ハードウェア的に世界一になってミッションは果たした。キラーアプリケーションとして世の中にどれだけ貢献できるだろうという議論があったはずで、総括が必要である。地球シミュレータは人間にとって非常に良い結果を得た、政策を進める上で、この延長線上で行かなくてはいけないのではないか。温暖化など地球環境はホットな話題であり、ここに具体的にどれだけ貢献したのか、どれだけ良くなったのかを明確に記述したほうがよい。地球シミュレータだけで良かったのではないか、と言われるかもしれないが、良かったけれども、なお、必要であると力説しなくてはいけない。特に地球シミュレータのケーススタディを正面から採り上げて、総括を行い、無駄なことは決してやっていいないとのストーリーで是非、記述するべきである。

事務局 おっしゃる通りである。

委員 産業界から見て、産学連携をどうあるべきかにも触れて欲しい。

事務局 了解。

委員 産学連携で、電機業界共通で基盤的なものをやるという話がある。それとは別に地球シミュレータが今年度から始まると思うが、能力を時間的に金で買う、すなわち有料化ということもあると思う。

事務局 今のご指摘は大事な視点である。産との関係において、従来は無かった視点である。他では産学官連携の機運が高まってきているが、計算科学技術に関しての産学官の連携については地球シミュレータの運用が一つのきっかけになっている。計算科学技術は自分のスーパーコンピュータで、企業からいうと秘密的に創薬とか自動車とか使われている。地球シミュレータでも、今、自動車工業会とも共同で少しずつ始まっている。次世代のスーパーコンピュータは大型かつ世界でもひとつとなりえる施設である。大型放射光施設であるSPring-8は、産学連携・共同利用はかなり経験がでてきたが、このようなスーパーコンピュータでも産学官連携に関しては、地球シミュレータをどう生かしているのかを含めて総括し、これから、アイデアを出してやって行きたい。地球シミュレータで産学官連携を進めるための国のプログラムとして、使いやすいシステムとするための支援策も考えている。その辺、知恵を絞ってやっていきたい。

委員 産学連携の部分を強いトーンで記述して欲しい。

委員 地球シミュレータに関する総括は大事である。ヘテロジニアスなリソースを使い切るキラーアプリケーションが何か、それは世の中をどのように変えるのかを明確にしなくてはならない。納得のいくキラーアプリケーションを決めていかないと、このプロジェクトがぼけてしまうのではないか。

  (6) 地球シミュレータの最新の状況とペタフロップス超級スーパーコンピュータ開発プロジェクトへの提言について
   
資料6に基づき、渡邉委員から説明の後、以下の通り、質疑応答が行われた。
(○:渡邉委員、●:委員、△:事務局)

   
委員 次世代シミュレータ構想でマルチプライヤに関して、何度聞いてもよく分からないのだが、単に速いネットワークで良いのではないか。

渡邉委員 マルチプライヤはジョブを振り分けるのではなく、マクロ層の変化を受けて、ミクロ層のシミュレータを駆動する。ベンダがベクトル側とスカラ側とが異なる可能性もあり、マルチプライヤを置く必要がある。マルチプライヤでは、バンド幅は大きくなくても良いが、レイテンシが重要であり、20マイクロセコンドくらいが必須である。普通のネットワークで構成すると、20ミリセコンド位になってしまう。

委員 インフィニバンドは10マイクロセコンドである。

渡邉委員 距離は如何か。

委員 光アダプタを使えば1,000メートルくらいになる。

渡邉委員 キロメートル、MPIでいくという考えはある。

委員 IMPIに対応していれば、マシン間は問題ないと思う。

渡邉委員 必ずしもそうではないのではないか。

委員 利用者は増えているという話だが、ただでさえ混んでいれば自分の所のコンピュータのほうが速い。ユーザを絞って、大量に使わせないようにしないと普通のコンピュータの成果と変わらないのではないかと思う。

渡邉委員 運営の問題であるので答えづらい。

委員 640ノードをフルに使うユーザにのみ、使わせるくらいでなければ納得いかない。80パーセントの大型ジョブの実績があるのだから、それをうまく整理された方が良い。

渡邉委員 そのようにしたいのはやまやまであるが、お金の出方の問題とか、いろいろしがらみがあるようである。

委員 地球シミュレータはもっと大型ジョブに特化するべきである。

渡邉委員 おっしゃる通りであり、これまでは、課題選定時の上限として、最低10ノード以上としてきたが、その上限を変えることは有りえるかもしれない。

委員 これは是非お願いする。米国のHPC関連の研究開発プロジェクトで、オークリッジよりは、リバモア研究所が一番怖い。2002年に300億円を投入して、ASC  PurpleBlueGeneを研究開発している。BlueGeneは汎用機に近いものになっている。専用機というが、ミスリーディングであると思う。Linuxクラスタで動くソフトウェアは全て動く。並列化効率でもあがってきて、ゴードンベルとかにおいて、BlueGeneが上位に入ってくるのではないかと思う。

渡邉委員 コンパイラの面では如何なのか。

委員 ベクトル化の部分で、日本ほどこなれていない部分があり、効率の悪さはあるが、Linuxクラスタで動いているMPIのプログラムはForkとか特殊なコードを使わなければ、30分もあればBlueGeneでも、メモリの上限(512MB)はあるが、間違いなく動く。決して過少評価してはいけない。いろいろなコードがポーティング、チューニングされ始めている。BlueGeneのアプローチだけが良いとは思わないが、高並列にチューニングが可能であるコードは、これからものすごく性能を出してくると思う。

渡邉委員 高並列というのは、99.9999パーセントの並列化が実現できるということなのか。

委員 気象のコードでも、地球シミュレータと同じ様なコードで50パーセントは出なくても、ノードごとに20〜25パーセントの実効効率を出している。ノードあたりの性能差は7〜8倍の差になるが、並列化効率を数倍あげると、地球シミュレータと同じ性能を出せるのではないかと思う。

渡邉委員 並列化効率は、本当に上がるのかが疑問である。

委員 BlueGene関係のペーパーがたくさん出てきているが、並列化効率に関して、4,000、8,000、16,000プロセッサレベルで、ほぼリニアにスケーリングしているデータが出ている。BlueGeneは、非常に怖い存在であり、決してLinpackマシンではない。彼らにどのように対抗するのか。BlueGeneを決して特殊マシンと言ってはいけない。

以上


(研究振興局情報課)

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