1アプリケーションから —「欲しかったのはこれじゃなーい!!」と叫ばないために

牧野淳一郎
東京工業大学理工学研究科
理学研究流動機構
SS 研 HPC フォーラム 2012 2012/8/20

概要• 「京」プロジェクトのデザインと概念設計• 現在進行中のプロセス– 昨年度のアプリケーション部会等の復習– 4 つのアーキテクチャイメージ
• おまけ: 今後の方向について2

3「京」プロジェクトのデザインと概念設計• 大体の時系列• ターゲットアプリケーション• 「概念構築に関する共同研究」

大体の時系列

4• 2004 年くらいから文科省の下の情報科学技術委員会、計算科学技術推進ワーキンググループで議論• 2005 年の「中間報告」– 8 分野からの要求をまとめた (ことになっている)– ベクトル 2PF +スカラー 4PF +「特定処理計算加速機」20PF• 2006 年度「次世代スーパーコ ンピュータ：概念構築に関する共同研究」実質的にはデザインコンペ。NFH の他、東大 (+天文台)、九大、筑波大等も参加

時系列続き5• 2005 年から 2006 年にかけて CSTP 評価委員会からボロクソに言われる。目標、アーキテクチャを文句がでないように色々変更。
• 2006 年初め (だったと思う) 開発実施本部設置、ヘッド:渡辺 (NECOB)• 2007 年夏: ベクトル (?PF) +スカラー (?PF) 合計 10PF 以上、と決定• 2009 年春: ベクトル担当の N が撤退• 2009 年 11 月 13 日 (金) 仕分け。「2 位じゃいけないんですか？」• 2010 年 10 月。プロトタイプ機が Green500 4 位にランクイン• 2011 年 6 月。8 割完成で Top500 1 位• 2011 年 11 月。全ノード動作で Top500 1 位。

ターゲットアプリケーション

6

http://www.nsc.riken.jp/target-application/target-application.htm
名前がでたのは 2007/4 だが選定は 2006/4 までになされていた:

1 Cavitation 有限差分法によるキャビテーション流れの非定常計算
2 COCO 超高解像度海洋大循環モデル
3 FrontFlow/Blue Large Eddy Simulation (LES) に基づく非定常流体解析
4 FrontSTR 有限要素法による構造計算
5 GAMESS ＦＭＯ分子軌道法計算
6 GNISC 遺伝子発現実験データからの遺伝子ネットワークの推定
7 LANS 航空・宇宙機解析における圧縮性流体計算
8 LatticeQCD 格子ＱＣＤシミュレーションによる素粒子・原子核研究
9 MC-Bflow 血流解析シミュレーション
10 MLTest オーダーメイド医療実現のための統計的有意差の検証ターゲットアプリケーション (2)711 Modylas 高並列汎用分子動力学計算ソフトウェア
12 NICAM 全球雲解像大気大循環モデル
13 NINJA/ASURA 天体の起源を探る超大規模重力多体シミュレーション
14 Octa 粗視化分子動力学計算
15 PHASE 平面波展開第一原理分子動力学解析
16 ProteinDF 巨大タンパク質系の第一原理分子動力学計算
17 RISM/3D-RISM 溶液内タンパク質の電子状態の 3D-RISM/FMO 法による解析
18 RSDFT 実空間第一原理分子動力学計算
19 Seism3D 地震波伝播・強震動シミュレーション
20 sievgene/myPresto タンパク質・薬物ドッキングシミュレーション
21 SimFold タンパク質立体構造の予測

但し
実際に性能評価に使われたのは HPL, FFT と以下の 7 個• SimFold, Modylas: 古典 MD• GAMESS, RSDFT: 量子化学
• LANS, NICAM: 流体• LQCD: 4 次元格子での CG 反復
この時点で、• したい計算• 高効率でできる計算• 高効率でできるがオーバースペックな計算の乖離8大雑把なアプリケーションの特性

9• 古典 MD、量子化学: メモリバンド幅もネットワークもあまりいらない• 流体: メモリバンド欲しい。ネットワークはそこそこ• QCD: メモリ量いらない。メモリバンド幅もネットワー
クも欲しい
これからわかること:• 一台で全て満たそうとすると帯に短し襷に長しになる• 低レイテンシ要求があるアプリケーションははいってない

「京」のデザインポイント

10• CPU:128Gﬂops, 64GB/s, 16GB
• ICC: リンク 5GB/s x 2 x 10, CPU 20GB/s, レイテンシ:論文に書いてない• 最近の計算機にしては B/F 重視• 最近の計算機にしてはネットワーク重視• CPU, ICC 別チップ

11

BG/Q との比較「京」 BG/Q
ピーク速度 (GF)
メモリバンド幅 (GB/s)
ネットワーク (GB/s)
電力あたり性能 (GF/W)

128
64
50.85

比率

204.8–
42.6
2.4
2
42.1(1/2.5)

演算性能あたりで、「京」は BG/Q の 2.4 倍のメモリバンド幅、 4 倍のネットワークバンド幅を持ち、 2.5 倍電気を食う。

どうしてこうなったか？
形式的な理由: 要求仕様にそう書いてあった• HPL 10PF
• 電力 30MW 以下• アクセラレータ付けるならやはり 10PF
• この範囲でアプリケーションの性能を上げること

12アプリケーションの側からは欲しいもの:
俺のコードが速く走る計算機をよこせ!
但し: 「俺のコード」には温度差あり• 必要ならアセンブラででも• コンパイラの出力見るのは基本だよね？
• プロファイラ使ったことある• OpenMP という言葉聞いたことがある• 並列化ってコンパイラがしてくれるんでしょ？

13最近の問題アセンブラで書くとかくらいではどうにもならないことがある• メモリ階層への対応• 分散メモリ並列化
アルゴリズム、データ構造どちらも根本から見直す必要あり

14

1 ステップもどって考える

15

何故分散メモリ+深いメモリ階層なのか？
チップ内の処理能力の増加に比べてチップ間データ転送能力が上がらないから
これは、言い換えると、現在の典型的マイクロプロセッサの設計では• 演算能力はデータ転送能力に比べて相対的に安い• これは製造コストだけでなく電力コストもということ

さらに言い換えると

16• 「京」より演算性能を大幅に上げるのは、メモリバンド幅やネットワークバンド幅をあげなくてもいいなら電力・コストを大きくは増やさなくてもできたはず• 逆に、 HPL 10PF だけならもっと安価にもできたかもしれない• メモリバンド幅を増やすなら全く別の作りかたもあったかも昨年度のアプリケーション部会

17• 去年の今頃に突然つくれという話が発生した。
• アーキテクチャ・コンパイラ・システムソフトウェアのほうは SDHPC 検討グループが横すべり• アプリケーションは戦略分野等から人を集めて急拠立ち上げ。9-11 月に集中的にミーティング、検討。
以下 11/15 の合同部会での牧野の報告から抜粋

予備検討の方針 (1)18• アーキテクチャ部会での検討では、B/F、メモリ量、ネットワークバンド幅等について非常に狭い範囲しか想定していないように思われた• 消費電力当り性能は、エクサスケール実現にとって大きな壁である。
• B/F はアプリケーションの効率に大きく影響する一方、消費電力当り性能にも大きな影響をもつ• メモリ量、ネットワークバンド幅も、大きく変えれば電力に影響する
アプリケーション側で、 B/F、メモリ量、ネットワークバンド幅の必要量をだしておこうWhat I learned from Steve Jobs
— Guy Kawasaki
1. Experts are clueless
2. Customers cannot tell you what they need
3. Jump to the next curve
4. The biggest challenges beget best work
5. Design counts
6. Changing your mind is a sign of intelligence
7. ”Value” is diﬀerent from ”price”
8. A players hire A+ players(いくつか省略)

19

予備検討の方針 (2)20• アプリケーション、アルゴリズムにより B/F 等への要求は変わる• 特に、同じアプリケーションでもアルゴリズムが変われば、またアルゴリズムが同じでも系のサイズ等だけによっても要求は変わるといった問題があるので、• 各分野に、重要なアプリケーション (計算法、系のサイズ等含めて) を選定してもらい、それぞれについて要求を見積もってもらう• それらをいくつかのタイプに分類できるかどうか検討するという方針を考えた。

アプリケーション40 アプリケーション
分野 数1721434485721

検討結果22(詳しい話は今日は省略)• B/F とネットワークバンド幅は関係あり。
• B/F 要求高いがネットワークは弱くていいものはある。逆はない• ランダムアクセス、非数値計算等、この軸ではよく表現できない要求もある• 大雑把に数種類にタイプわけできそうタイプわけの観点

23

観察:• B/F は 0.1 以上の高いものと、桁で小さいものに分かれる• メモリ要求にも非常に幅がある
注意事項:• 分野によってはまだ十分な検討が進んでいない• 分野によっては、そもそもアプリケーション・アルゴリズムの進化が速いために定量的な要求を明確にしにくいところもあるタイプわけの観点

24「アプリケーションタイプ」でなくて「アーキテクチャタイプ」としてみた。

• そのほうが物理的制約をイメージしやすい• アーキテクチャ側との議論もしやすい？

25

タイプわけ
以下の 4 タイプ
タイプ
ベースライン

B/F

0.1
SoC
4アクセラレータ 0.001
バンド幅重視1メモリ量消費電力 演算性能)

バンド幅(1TF)(1EF) (20MW)(20MW)
10-100GB20MW
1EF
0.1EB/s
5-10MB 2-5MW
4-10EF 16-40EB/s
1-10GB 4-10MW
2-5EF
2-5PB/s
1TB 120MW
0.15EF 0.15EB/s最終レポートではこんな感じ (1)26最終レポートではこんな感じ (2)

27

28

要するに
報告書での用語 アプリ部会のつけた名前

具体的イメージ

汎用

ベースライン「京」の延長

容量・帯域

バンド幅重視演算重視

アクセラレータ

メモリ削減

SoC

NEC SX-9 の延長
GRAPE-DR,GPGPU
...

注意

29

• 「汎用」は汎用ではない (「京」でうまく効率がでないアプリケーションはいくらでもある)• 「容量・帯域」が本当にそのどっちかでも実現できる設計解があるかどうかは自明ではない• 演算重視は要するに B/F 要求が低いものを対象にする• 「メモリ削減」はオンチップメモリないし 3 次元実装でバンド幅を増やすのが本質。小容量になるのは結果汎用/ベースライン• 「京」の延長• B/F 0.1 ∼ 0.2?
• 富士通さん頑張って30

演算重視/アクセラレータ

31• メモリ帯域が少なくて良いとなったアプリケーションの大半が量子系 (密行列の直交化や対角化が計算量のほとんどを占める)• 後は大規模な粒子系• GPGPU 的なものでいいが、アクセラレータ側に外部メモリはあまりなくてもいい (そちらにメモリあるならホストはなんのため?という問題も)• GRAPE-DR ベース？

メモリ削減/SoC

32• 想定アプリケーション: 小サイズ MD、流体、QCD 等• 大サイズ差分法を out-of-core でできるかどうかは要検討• 外付けメモリがないか、極端に低バンド幅• 軽量コアを非常に多数集積して、電力当り性能を上げる• オンチップメモリに対しては 高 B/F• メモリはチップ当り 1GB 以下程度？
• ネットワークは 100GB/s 程度？

容量・帯域/バンド幅重視• SX-9 の延長• NEC さん頑張って、、、

33

34

演算重視・メモリ削減のもうちょっと具体的なイメージ• 大雑把には: 70-80 年代の大規模 SIMD マシンを 1 チップ化。Goodyear MPP, CM, MasPar 等• 例: CM-2。 2048 FPU, トータル 512MB メモリ• 14nm だと 16384 FPU, 256-512MB メモリくらいが入るかも• 考えるべきことは– コア内部アーキテクチャ– コア間接続– チップ間接続

コア内部アーキテクチャ

35

GRAPE-DR PE の構造
マスク(M)レジスタ

マルチプレクサ

PEID
BBID

マルチプレクサx

T レジスタ
汎用レジスタファイル 32W• 浮動小数点演算器

ローカルメモリ
256W• 整数演算器

+A
B
整数ALU

• レジスタ
共有メモリ
ポート

共有メモリ
ポート

• メモリ 256 語(今回増やす)

36

GRAPE-DR PE レイアウト

0.7mm by 0.7mm
Black: Local Memory
Red: Reg. File
Orange: FMUL
Green: FADD
Blue: IALU

37

他の検討点38• 演算器の方式 (単精度重視か倍精度重視か)、数• 加算・乗算以外の機能。逆数平方根？もうちょっと汎用の関数評価？
• 制御方式 (牧野の好みは少なくともチップ内は完全 SIMD)

チップ内ネットワーク

39

考え方 2 つ• 想定するアプリケーションに必要な通信パターンだけに対応• 汎用ルーティングネットワーク
使う側の気分としては:• (アプリケーションの次元での) 隣接通信
• 縮約・放送 (ブロックにわけたものも必要？)くらいがあれば十分ではないかという気も。任意の 2 コア間とかもちろんあれば便利かもしれないけど、、、

チップ間ネットワーク

40• 原理的には、チップ内ネットワークを延長できればよい• 現実的には、バンド幅、レイテンシが問題• レイテンシは実装方法を考えたい• バンド幅については、電力・アプリケーションの要求の両方の検討が必要

今後の方向
• 今年度、来年度 feasibility study• その後？5 年くらいで開発？

41

最悪シナリオ• 3 つの FS チームが「競争」に• 同じようなデザインになる• 1 つ作るだけになる(まあその、どこかで聞いたような話)

42

43

前回のキーポイント: 概念構築のためのなんとか• 概念構築といいつつすでに枠が決まっていた––––

HPL 10PF
電力 30MW 以下アクセラレータ付けるならやはり 10PF
この範囲でアプリケーションの性能を上げること• その結果、各社の提案が収斂した
以下、2012/6 に公開になった当時の会議資料から

(2012/6 公開)

44

(2012/6 公開)

45

(2012/6 公開)

46

(2012/6 公開)

47

NH/F の比較

48

• ベクトル・スカラーで違うはずだったが、アーキテクチャパラメータはほとんど同じものに収斂
• さらに消費電力等も収斂• さらにベンチマーク性能も収斂おまけ: アクセラレータについては？

(2012/6 公開)49

概念設計評価時の判断

50• アクセラレータ案の説明資料には消費電力「-10MW」という謎の表現が。議事録には「10MW 以下くらい」とある。
• 実際の提案の数字は公開時注意書きにあるように 0.881.7MW

アクセラレータを採用しなかった理由
公式の説明
2 者のシステム構成により、目標性能達成の見込みが確認できたため、アクセラレータの採用は考慮しない• 目標 = LINPACK 10PF + HPCC 4 種 1 位• アプリケーションのことはすっかり忘れられた、、、

51

教訓的なもの52• プロジェクトは (実現可能なら) 設定した目標通りのものが実現される• 「プログラムは思った通りではなく、書いた通りに動く」と同じ• なので、Top500 1 位とか HPCC 1 位とかを目標にしてアプリケーションのことを忘れられては困る• 目標をちゃんと決めよう