エクサスケールを目指して──2020年までに「京」の100倍速いスパコンは作れるか?(SS研HPCフォーラム2013レポート)

190年ほど前にチャールズ・バベッジが階差機関を考案して以来ずっと、計算を速く実行するのはコンピュータの1つの大きな役割だ。その中でもスーパーコンピュータは、「科学技術計算をひたすら速く実行する」ことに特化した怪物マシンで、世界最高速が常に競われている。

現在、スーパーコンピュータのランキング「TOP500」で1位にランクされているのは、中国の「天河2号(TH-2)」で、Rmax(実効性能値)で33.86P(Peta、ペタ)FLOPSをマークしている。ちなみに我が国の「京」はおよそ10PFLOPSで最新のランキングでは4位となっている。次の競争としては100PFLOPSが見えてきており、さらにその10倍であるE(Exa、エクサ)FLOPS台──エクサスケール──に向けて、米国でも日本でも2020年を目標にした国レベルの施策が動いている。

そんな中、8月27日に、大学や研究所などの科学技術分野のコンピュータ利用機関が中心となった研究会(任意団体)「サイエンティフィック・システム研究会」(SS研)が、「エクサスケール時代のコンピュータ技術」というテーマで「SS研HPCフォーラム2013」を開催した。実際に国内でエクサスケールのHPCを研究している研究者による講演などが行われた。参加者約200名で、会場はほぼ満席。主催者によると、過去の同フォーラムと比較して、(SS研)会員以外の参加が多かったという。

ここでは、その模様をレポートする。

写真:SS研HPCフォーラム2013の会場の様子

SS研HPCフォーラムは、SS研の会員以外でも参加が可能。およそ200名の参加者で会場はほぼ満席となった。

2020年までにエクサスケールは実現しない?

「Why we need Exascale, and why we won't get there by 2020」(なぜエクサスケールが必要で、なぜ2020年までに実現できないか)。こんな挑発的とも、お茶目ともとれるタイトルで登場したのは、この日最初のセッションである招待講演のHorst D. Simon氏だ。Simon氏はHPCの世界的著名人で、年2回発表されるHPCランキング「TOP500」の編纂にも参加している。現在はローレンス・バークレー国立研究所の副所長(Deputy Laboratory Director)を務めている。なお、講演冒頭でSimon氏はタイトルについて「単に私の意見だから、信じる必要はないよ」と笑いながら断っていた。

写真:講演するHorst D. Simon氏(Lawrence Berkeley National Laboratory)

「Why we need Exascale, and why we won't get there by 2020」と題して講演した、Horst D. Simon氏(Lawrence Berkeley National Laboratory)。

Simon氏はまず、HPCのプロセッサ技術として、x86やSPARCなどの「マルチコア」、低消費電力のコアを多数使った「組み込み系メニーコア」、GPUを使った「GPU/アクセラレータ」の3種類のアプローチが並立していることを説明した。そして、GPU/アクセラレータの例として「天河2号」を、組み込み系メニーコアの例としてIBMの「Blue Gene/Q」を、マルチコアの例として日本の「京」を挙げた。

そして、マルチコアについてはIBMが「Blue Waters」を中止したことを指摘し、組み込み系メニーコアについてはBlue Geneが最後の砦であろうと述べ、「2015年にはトップ10すべてがGPU/アクセラレータ方式で占められるだろう」との予想を語った。

続いてSimon氏は、「『2019年11月までにエクサスケールに到達しないだろう』と、個人的にThomas Lippert氏(Julich supercomputing centre)と賭けをしている。残念ながら私が勝ってしまいそうだ(笑)」とユーモアをまじえて言ってみせた。T(テラ)FLOPSからPFLOPSへは直線的な進化だったが、PFLOPSからEFLOPSへは違ったものになり、膨大な予算を必要とするだろうという。

Simon氏が指摘する要因の1つが、消費電力だ。TOP500でHPL(High- Performance Linpack)ベンチマークを走らせるにも、エクサスケールでは5.8日にも渡ると予想されており、それだけトータルの消費電力が増えることになる。TOP500でも2012年から指標の1つとして電力消費の値を加えている。Simon氏は、消費電力あたりのFLOPSの経年変化を示すグラフを見せ、一見順調に上がっているようにも見えるが、実は2010年に急激に上がり(Blue Gene/Qの世代)、また伸びがゆるやかになっており、3種類のアプローチのほかに新しい技術が出ないと再び大きく伸びないと論じた。

Simon氏のスライド「The Problem with Wires」

データ移動のコストも問題だとSimon氏は指摘する。

スライド:「Why I believe that I will win my bet」

Simon氏が示した、2020年までにエクサスケールが実現しない「理由」。

こうしたことからSimon氏は、これまではピークのクロック周波数やFLOPSのコストがHPCによる記録への挑戦の制約だったが、これからは電力消費やデータ移動のコストが制約になるだろうと説明した。そして、「FLOPSが(相対的に)重要でなくなるなら、“エクサなんとか”という言葉はブランドとして意味がなくなる」とジョークを語った。これは、エクサスケールが重要ではないということではなく、CPUの処理能力向上だけではエクサスケールを実現できない、新しいコンピューティングパラダイムが必要だ、という意味に私は解釈した。

エクサスケールに向けた日本での取り組み

この日のフォーラムのもう1つの主要テーマが、日本でのエクサスケールHPCに向けた研究の紹介だ。文部科学省による「将来のHPCI(High Performance Computing Infrastructure)システムに関する調査研究」の実施機関に選定された、東京大学、筑波大学、東北大学の3つのプロジェクトについて、当事者による報告がなされた(同調査研究では、他に理化学研究所が選定されている)。

まず、筑波大学の朴泰祐氏が、全体を紹介した。同氏によると、文科省の取り組みは、「ポスト『京』」のために、2018~2020年ごろを見すえたアーキテクチャのプロポーザルや調査など一連の研究を行う、フィジビリティスタディ(Feasibility Study)の段階のものだという。さらに朴氏は、3つのプロジェクトについて、東大のプロジェクトがレイテンシコア(従来型のCPU)を利用したもの、筑波大のプロジェクトがアクセラレータを利用したもの、東北大のプロジェクトがベクトル型を利用したものと、それぞれの位置づけを紹介した。

東大のプロジェクトについては、東京大学の片桐孝洋氏が発表した。「京」のCPUを元に、メニーコア化やSIMD化、通信機構の高度化を加えたCPUを用いている。実際の使い方を想定してシステムを設計するというアプローチをとっており、対象アプリケーションとして、物性予測の「ALPS/looper」、Siナノワイヤ等のシミュレーションの「RSDFT」、気象シミュレーションの「NICAM」、海洋シミュレーションの「COCO」の4つを想定。それぞれのアプリケーションの特性ごとに、性能評価ツールを使って性能を予測しチューニングするという取り組みが紹介された。

筑波大のプロジェクトについては、筑波大学の児玉氏が発表した。こちらはアーキテクチャ重視のアプローチで、演算加速機構(アクセラレータ)による並列大規模システムを研究しているという。オンチップメモリを演算コアに直結し、2048チップによるグループをネットワークで2次元メッシュにした構造となる。モジュールメモリが律速になることや、プログラミングモデルが重要になることなど、アーキテクチャ上の特徴が解説された。

東北大のプロジェクトについては、参加している海洋研究開発機構の板倉憲一氏が発表した。このプロジェクトは、対象とするアプリケーションの分野を「総合防災」「ものづくり」の2つに絞り、そのための性能要求要件にあわせてシステムを開発するのが特徴だ。具体的には、総合防災アプリケーション連携として、地震発生のRSGDX、地震伝播のSeism3D、地盤振動のMMA、津波発生/遡上のSTOC-CADMASのそれぞれのアプリケーションから要求性能を求め、積層型DRAM(HMC)や、fat treeとトーラスの複合型のネットワーク、アプリケーション間の通信方法などの要素技術まで設計するという。

写真:パネルディスカッションの様子(SS研HPCフォーラム2013)

時間が押し気味だったもののパネルディスカッションでは活発なやり取りが行われた。向かって左から、朴 泰祐氏 (筑波大学)、片桐 孝洋氏(東京大学)、 児玉 祐悦氏(筑波大学)、板倉 憲一氏(海洋研究開発機構)。

それぞれの発表の後、朴氏をモデレーターにパネルディスカッションも行われた。まず、それぞれ実現する場合の課題としては、東大の片桐氏は「京」のアプリケーションを効率よく動かせるかどうか、筑波大の児玉氏はアプリケーションを選ぶという特性とそれを軽減するためのプログラミングモデルについて、海洋研究開発機構の板倉氏は最高速のアプリがエクサに到達するだけでなく使いやすいシステムとなることを挙げた。

また、3つのプロジェクトの発表とも、CPUが10nmプロセスに微細化されることを前提としていることについて、会場から微細化の限界があるのではないかと質問がなされた。それに対しては、2020年ごろではシリコンのプロセスがなんとかなるという想定で考えていること、10nmから先はまた別の技術が必要になるだろうという回答がなされた。

リチウムイオン電池のメカニズムを「京」で解明

HPCを利用する側の事例のセッションも設けられ、富士フイルム株式会社の奥野幸洋氏が、リチウムイオン2次電池内の化学反応解析に「京」を利用した例を紹介した。

写真:「民間企業での『京』利用:第一原理計算によるリチウムイオン2次電池内の化学反応解析」と題して講演した、奥野 幸洋氏(富士フイルム株式会社)。

「民間企業での「京」利用:第一原理計算によるリチウムイオン2次電池内の化学反応解析」と題して講演した、奥野 幸洋氏(富士フイルム株式会社)。

研究の背景として、リチウムイオン電池が家電製品用だけでなく自動車用などの大型化へのニーズが高まっていて、高出力化と安全性が求められていると説明。そのために、リチウムイオン電池の添加物を少量入れるとSEI(不動態皮膜)が反応し特性や安全性が向上することが分かっているが、その機構が不明だったと奥野氏は説明した。

スライド:Liイオン電池のしくみ

SEI(不動態皮膜)が作られる反応の詳細を「京」によるシミュレーションで解明(参考:富士フイルムのプレスリリース「スーパーコンピューター「京」を用いてリチウムイオン電池の電解液の反応過程を解明」)。

しかし、電池の中の反応を直接観察するのは困難なため、シミュレーションで解析した。これまで、量子化学計算によるクラスター計算はなされていたが、周囲の溶媒や時間経過などさまざまな要素を外した単純なものだった。そこを、溶媒効果や、系の時間変化を追って計算してシミュレーションするのだが、効率的な計算手法を用いても計算負荷が大きいので、「京」を利用したという。

シミュレーションの結果、電子還元の様子が想像されていたものと違うことや、添加剤どうしの反応ではなく還元された電解質との反応によるものであるというメカニズムが判明した。これには、ガスが発生しているという実験データが先にあり、シミュレーションの結果がそれに合致したことから、計算の確度が高いと考えているという。

リチウムイオン電池という普及した製品でも性能向上の原理が分かっていなかったことや、それを「京」によるシミュレーションで解明したという点が、物性物理などになじみのない筆者にも興味深く感じられた。

FXシリーズの今後

この日最後のセッションでは、富士通の追永勇次氏により、同社のスーパーコンピュータ製品「FXシリーズ」(現行のFX10は、「京」で採用された技術が用いられている)の今後の取り組みについて語られた。

写真:「FXシリーズの今後の取り組みについて」というテーマで講演した追永勇次氏(富士通株式会社)。

「FXシリーズの今後の取り組みについて」というテーマで講演した追永勇次氏(富士通株式会社)。

いまの京/FX10への要望としては「消費電力あたりの性能をもっと上げてほしい」「実装密度をもっと上げてほしい」「1コアあたりの性能を引き出すのが難しい」「C/C++プログラムの性能が出ない」といったものがあるという。また、そのための要素技術の面では、L1キャッシュの容量不足や、マイクロアーキテクチャの問題、命令セットの問題、コンパイラの最適化やオプションのサポートの問題などがあるという。

そのため、プロセッサとインターコネクトのSoC化や、20nmプロセスの採用、メモリの脱DIMM、光伝送などを検討しているという。また、「今後のHPCプロセッサはSIMDが鍵」ということで、4SIMDへの強化や、単精度倍幅SIMDや整数SIMDサポートなども行う。そのほか、L1キャッシュを64KBに強化、マイクロアーキテクチャを改善してOut-of-Orderリソースや分岐予測を強化、IFの効率化なども予定。コンパイラも、並列化の強化や、最適化の拡大、C/C++の改善などをほどこすという。

追永氏は最後に、「マラソンと同じように、HPCランキングでもトップグループを維持するのが重要」として、次期FXでも現状の課題に真摯に対応すると語った。


変更履歴:
2013年9月3日(火):Horst D. Simon氏の肩書き(Deputy Laboratory Director)を「副主任研究員」としていましたが、「副所長」のほうが適切との指摘を受けましたので、そのように修正いたしました。ご指摘いただき、ありがとうございました。

この記事を、以下のライセンスのいずれかで提供します:「GPLv2またはそれ以降」「GFDL」「CC-BY-SA

これ以外のライセンスをご希望の場合は、お問い合わせください。

Comment