HPC 分野におけるGPU 活用技術アクセラレータ技術 WG 成果報告 SS 研アクセラレータ技術 WG 取りまとめ役井上弘士 ( 九州大学 ) 1

Size: px

Start display at page:

Download "HPC 分野におけるGPU 活用技術アクセラレータ技術 WG 成果報告 SS 研アクセラレータ技術 WG 取りまとめ役井上弘士 ( 九州大学 ) 1"

つかさがうん
4 years ago
Views:

1 HPC 分野におけるGPU 活用技術アクセラレータ技術 WG 成果報告 SS 研アクセラレータ技術 WG 取りまとめ役井上弘士 ( 九州大学 ) 1

2 発表内容ワーキンググループ (WG) 設置の背景 WG 活動概要 GPU を手軽に使って性能が改善するか? GPU に不向きとわれるアプリは本当に不向きなのか? 将来のアクセラレータ活用のあるべき姿は? 2

3 WG 設置の背景 3

4 エクサ実現へのチャレンジエクサフロップス級スパコンの実現における最大の課題は? 消費電の壁スパコンを実現するには? 京を基準にすると消費電 2x で性能 100x 1E+10 Gflops (Rmax) 1E+09 1E+08 1E+07 1E x 2x 1EFlops 1E+05 1E Power (KW) 20MW 4

5 DARPAIPTO ExascaleComputingStudy 既存マシンをベースにしたスケーリングによりシステム性能を予測消費電と積 ( 最ラック数 ) 制約を考慮ノード名説明システム例プロセッサ例 HeavyNode(HN) 高性能プロセッサ搭載型ノード RedStorm Intel,AMD などのプロセッサ LightNode(LN) 組込み向けプロセッサ搭載型ノード BlueGene/L,/P PPC440,450 AggressiveNode(AN) 1EFlops のシステムを前提とした仮想ノード無し無し 5

DARPAIPTO ExascaleComputingStudy 半導体デバイス ITRS@2006 メモリ総容量理論ピーク性能

#DRAM チップルータベースと同じ割合で一定 FullyScaledPowerModel プロセッサ ITRS@2006 主記憶

6 DARPAIPTO ExascaleComputingStudy 半導体デバイスメモリ総容量理論ピーク性能ノード消費電モデル SimplisticllyScaledPowerModel プロセッサ主記憶 (DRAM) #DRAM チップルータベースと同じ割合で一定 FullyScaledPowerModel プロセッサ主記憶 (DRAM) #DRAM チップ性能ルータ性能コアメモリ (DRAM) ルータラック Cache プロセッサノードボード 6 システム

7 DARPAIPTO ExascaleComputingStudy は到達できない! Fully で 50 60x,Simplisticaly で 10x の性能向上が必要何らかの質的な変化が必要では? アクセラレーション技術 Figure 7.14: Light node strawman performance projections 1EFlops 50~60x 10x 消費電力制約無し W Simplistically 20MW Simplistically W Fully 20MW Fully LN: Light Node の結果

8 本 WG の狙い現在最も有望なアクセラレーション技術 GPU GPU 向きアプリを対象とした多くの事例報告素朴な, でも, 本質的な疑問 GPU を手軽に使って性能が改善するか? PGI コンパイラを用いたライトなチューニング GPU に不向きとわれるアプリは本当に不向きなのか? GPU に不向きとして知られるアプリを対象にヘビーなチューニング上記の調査を通して将来のアクセラレータ活用のあるべき姿を模索議論 8

9 WG 活動概要 9

10 メンバーと活動内容氏名担当幹事村上和彰九州大学所属会合日時活動内容第一回 2009 年 10 月 29 日 ( 木 ) WG 全体スケジュールの議論今後の議題検討推進委員尊之東京工業大学遠藤敏夫東京工業大学川原佳理化学研究所第二回 2010 年 1 月 19 日 ( 火 ) 会員報告 (PGI アクセラレータコンパイラコーンビーム再構成の高速化初心者による GPU プログラミング事例複合型計算機向けソフトウェア開発環境 ) 富士通報告 (GPGPU プログラミングの状況 GPUSIM からた GPU) 滝沢寛之伊野文彦東北学大阪大学第三回 2010 年 4 月 7 日 ( 水 ) 会員報告 (LinpackonGPU 搭載スパコン Tsubame) 富士通報告 (OpenCL の評価 ) OpenCL に関する議論井上弘士九州大学本田宏明九州大学堀田耕郎富士通 ( 株 ) 第四回第五回 2010 年 7 月 14 日 ( 水 ) 2010 年 12 月 3 日 ( ) 会員報告 (PGI コンパイラ評価 ) 富士通報告 (nvidia 新 GPU 評価 ) 会員報告 ( アクセラレータの大規模システム導入課題 LinpackonTsubame2) 丸山拓富士通 ( 株 ) 坂口吉生富士通 ( 株 ) 第六回 201 年 3 月 25 日 ( ) 会員報告 (PGI コンパイラ評価 ) 富士通報告 ( 分子軌道法プログラムの GPU 化検討 ) 佐々木啓富士通 ( 株 ) 久門耕一 ( 株 ) 富士通研究所成瀬彰 ( 株 ) 富士通研究所第七回第八回 201 年 8 月 19 日 ( ) 2012 年 1 月 19 日 ( 木 ) まとめ会員報告 (CUDAFortran 評価 ) 富士通報告 ( 分子軌道法プログラムの GPU 化結果 ) 10

11 GPU を手軽に使って性能が改善するか? 11

3 人の開発者による PGI アクセラレータ利事例 PGI アクセラレータ : nvidiagpu 向けのディレクティブ挿入方式のプログラム開発言語環境 3 人の開発者開発者 A OpenMP MPI による並列プログラム開発経験はあるが,PGI アクセラレータの使用経験は無し.

12 3 人の開発者による PGI アクセラレータ利事例 PGI アクセラレータ : nvidiagpu 向けのディレクティブ挿入方式のプログラム開発言語環境 3 人の開発者開発者 A OpenMP MPI による並列プログラム開発経験はあるが,PGI アクセラレータの使用経験は無し. 開発者 B 開発者 C 計算科学分野のアプリ開発経験は豊富. 逐次プログラム開発が主体であり, プログラムの並列化はあまり詳しくない. 並列処理のエキスパートであり,CUDA OpenCL でのプログラム開発経験がある. 3 種類のアプリ姫野 BMT 2D-FDTD 分子軌道法 12

13 実験結果姫野 BMT 2D-FDTD 分子軌道法 GFLOPS Directive 数開発工数 GFLOPS Directive 数開発工数 GFLOPS PGIver 時間 ( 学習に数日 ) GPU コード生成できず PGIver 分 CUDA 版 (by 開発者 C) CUDA 版 (by 開発者 B) XeonX GHz1 コア XeonX GHz4 コア 50 数日程度エキスパート ( 開発者 C) の CUDA 版実装と比較して 40% 程度の性能 13

14 GPU に不向きとわれるアプリは本当に不向きなのか? 14

15 分子軌道法とは分子内において, 主に電子がどのような運動をしており, どのようなエネルギーを持っているかを量化学的計算により求める方法の一つ分子物性の解析創薬新素材の開発 ex) プリンタのカラーインク液晶ディスプレイ 15

16 GPU での高速化は難しいらしい分子軌道法プログラムの GPU 化は一般的に難しいとされている数例の報告のみオリジナルコードコードが複雑ステップ数大 PGI アクセラレータコンパイラのディレクティブの方法では GPU へのオフロードコードは生成されず GPU 使用の問題点倍精度計算の使開平逆数指数関数計算が必要条件分岐計算レジスタ量が不分シェアードメモリを利のための適切な法が不明確デバイスメモリサイズの制限などなど 16

17 分軌道法プログラムの処理フロー分子の座標座標電子数基底関数データなどを入力重なり積分 S, 1 電子ハミルトン行列 H core および 2 電子積分を計算重なり積分を Cholesky 分解 (S=U T U) 密度行列の初期値 (D 0 ) を設定積分駆動型アルゴリズムによる 2 電フォック列計算 Obara のアルゴリズムによる積分計算法計算全て C 言語で記述密度行列と 2 電子積分から 2 電子ハミルトン行列 G を計算密度行列を更新 F=H core +G を計算 FC=SCε を解く C から新たな密度行列 D を計算 N N 2 G [ ] ij D kl k l i j k l i k j l no 密度行列が収束した? yes 収束した F, C, D などを用いて望みの期待値 ( エネルギーなど ) を計算 2 電子積分計算 (ERI) を含む G 行列計算式 17

18 ボトルネックは G 列計算分子軌道法プログラムの高速化 G 列計算の速化 CPU Core-i7 2600K 3.4GHz (1core) Compiler Intel v12.1 (-O3) Program Kyudai-HFR Input data h16o8 (24 atoms) Elapsed time sec 18

19 CPU 向け並列化 19

20 係数列作成 1 st loopbegin 2 nd loopbegin 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend G 列計算の概要 & OpenMP によるCPU 向け並列化 ompparallelfor 1 st loo pの iteratio nをスレッドに分配 ompatomic 他スレッドと同じ箇所を更新する可能性 G[ij]+= 4*x*D [kl] G[kl]+= 4*x*D [ij] G[ik]-= x*d [jl] G[il]-= x*d [jk] G[jk]-= x*d [il] G[jl]-= x*d [ik] 20

実際には 6 種類の積分計算係数列作成 1 st loopbegin 2 nd loopbegin 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend (ss,ss) タイプ (ps,ss)

21 実際には 6 種類の積分計算係数列作成 1 st loopbegin 2 nd loopbegin 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend (ss,ss) タイプ (ps,ss) タイプ (ps,ps) タイプ (pp,ss) タイプ (pp,ps) タイプ (pp,pp) タイプ CPU:Core-i72600 K3.4GHz (1core) Compile r:intelv12.1(-o3) Program:Kyudai-HFR Input data:(h 2 O) 8 (24atoms) Elapsedtime:14.29sec 21

22 OpenMP による並列化効果 ( コア数 :1 4) CPU Core-i72600 K 3.4GHz (1-4cores) Compile r Intelv12.1 (-O3-openmp) Program Kyudai-HFR 6 種類の積分型を全て OpenMP で並列化 Inputdata h16o8(24atoms) 22

23 性能積分型実時間 (1 コアに対する性能向上 ) CPU GPU 1 コア 4 コア (ss,ss) (ps,ss) (ps,ps) (pp,ss) (pp,ps) (pp,pp) 246 (1.0x) 279 (1.0x) 1 2 (1.0x) 67 (1.0x) 62 (1.0x) 12 (1.0x) 66.2 (3.7x) 85.8 (3.3x) 39.6 (3.1x) 21.3 (3.1x) 21.0 (3.0x) 4.0 (3.0x)? 23

24 GPU 向け並列化 (NAÏVE 実装 ) 24

25 G 列計算処理 ((ss,ss) 積分型 ) 係数列作成 1 st loopbegin 2 nd loopbegin 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend 係数列作成係数列数 :16 種総量 :2.4MB( 依存 ) 1 st &2 nd loop: ループ回数 :139,656( 依存 ) ERI 計算 : ループ回数 :81( 依存 ) ERI 値 :1 種 ( 積分型依存 ) G 配列更新前出 ERI 値と関連する部分を更新 G 列更新 :6 箇所 ( 積分型依存 ) G 配列要素数 :1,596( 依存 ) (*)Inputdata:(H 2 O) 8 24atoms 25

26 G 列計算の GPGPU 化係数列作成 1 st loopbegin 2 nd loopbegin 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 1 st &2 nd loop: ループ回数 :139,656( 依存 ) 1 st &2 nd loo pの各 iteratio nを 1スレッドに割当 G 列更新 2 nd loopend 1 st loopend (*) Input data: h16o8 (24 atoms) 26

27 係数列作成 1 st loopbegin 2 nd loopbegin G 列計算の GPGPU 化 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 ERI 計算 : ループ回数 :81( 依存 ) ERI 値 :1 種 ( 積分型依存 ) マルチスレッド化各 ERI 値の計算には 5 スレッド使 ( 定量的な解析より ) G 列更新 2 nd loopend 1 st loopend (*) Input data: h16o8 (24 atoms) 27

28 係数列作成 1 st loopbegin 2 nd loopbegin ボトルネックはどこに? 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend N スレッド並列 (*)N=2 81 N-1 スレッドは待機 (6 回の atomic 操作 ) (*) Input data: h16o8 (24 atoms) 28

係数列作成 1 st loopbegin 2 nd loopbegin G 列計算の GPGPU 化 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend

29 係数列作成 1 st loopbegin 2 nd loopbegin G 列計算の GPGPU 化 3 rd loopbegin 4 th loopbegin 初期積分計算垂直漸化式計算 4 th loopend 3 rd loopend 水平漸化式計算 G 列更新 2 nd loopend 1 st loopend 部分 G 列更新 ERI 値毎に関連する箇所を更新 G 列更新箇所 :6 ( 全要素数 :1,596) 更新箇所は不連続他スレッドが同時に同じ G 列要素を更新する可能性 atomiccas() による排他処理 CAS: CompareAndSwap (*) Input data: h16o8 (24 atoms) 29

30 GPU 環境 Tesla C2050 Fermi 世代 CUDA 4.2 Stream Multi-processor Register Files (128KB) CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC L1+Shmem:64KB (*) CC = CUDA Core CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC SM L2(128KB) Memory Controller GDDR5 64bit (x14) X-Bar (x6) SM L2(128KB) Memory Controller 64bit GDDR5 30

31 性能積分型実時間 (1 コアに対する性能向上 ) CPU GPU 1 コア 4 コア Naïve (ss,ss) (ps,ss) (ps,ps) (pp,ss) (pp,ps) (pp,pp) 246 (1.0x) 279 (1.0x) 1 2 (1.0x) 67 (1.0x) 62 (1.0x) 12 (1.0x) 66.2 (3.7x) 85.8 (3.2x) 39.6 (3.0x) 21.3 (3.1x) 21.0 (2.9x) 4.0 (3.0x) 45 (5.4x) ? 31

32 GPU 向け並列化 ( 実装アルゴリズムの最適化 ) 32

33 ボトルネックはどこに存在する? atomic 操作を外すと CPU(1core) 246ms GPU (2x2x5) 45ms(5.4x) GPU (w/oatomic 操作 ) 25ms(9.8x) (*) ただし正しい結果は得られないボトルネックは G 列計算の atomic 操作これをなんとかしないと速くならない! 33

34 Kernel 分離 :atomic 操作を無くす! 1 st &2 nd loopbegin ERI 計算 G 列更新 1 st &2 nd loopend ERI 値の計算直後に関連する G 列要素を更新分離 1 st &2 nd loopbegin ERI 計算 (ERI 値をメモリに WRITE) 1 st &2 nd loopend + 1 st &2 nd loopbegin (ERI 値をメモリから READ) G 列更新 1 st &2 nd loopend ERI 値をメモリに記録するオーバーヘッドは高いメモリバンド幅で隠蔽 ( と期待 ) 34

35 性能積分型 (ss,ss) (ps,ss) (ps,ps) (pp,ss) (pp,ps) (pp,pp) 実時間 (1コアに対する性能向上) CPU GPU 1 コア 4 コア Naïve カーネル分割 (1.0x) (3.7x) (5.4x) (1.0x) (3.2x) (1.0x) (3.0x) (1.0x) (3.1x) (1.0x) (2.9x) (1.0x) (3.0x) -- (23.4x) 16.2 (17.2x) 12.6 (9.7x) 6.3 (10.6x) 10.1 (6.1x) 9.6 (1.3x)? 35

36 性能積分型実時間 (1 コアに対する性能向上 ) CPU GPU (ss,ss) (ps,ss) (ps,ps) (pp,ss) (pp,pp) 1 コア 4 コア Naïve カーネル分割 (1.0x) (3.7x) (1.0x) (3.2x) (1.0x) (3.0x) (1.0x) 62 (1.0x) 12 (3.1x) 21.0 (2.9x) 4.0 (1.0x) (3.0x) (5.4x) 積分型により性能 UP 率にきな違い複雑な積分型は (pp,ps) GPUで性能向上難しい --? さらなるチューニングを試みる! -- (23.4x) 16.2 (17.2x) 12.6 (9.7x) 6.3 (10.6x) 10.1 (6.1x) 9.6 (1.3x) GPU 向き繰り返し多計算単純 GPU 不向き繰り返し少計算複雑 36

37 積分型による G 列計算処理の違い係数行列作成 1 st loop begin 2 nd loop begin 3 rd loop begin 4 th loop begin 初期積分計算垂直漸化式計算 4 th loop end 3 rd loop end 水平漸化式計算 G 行列更新 2 nd loop end 1 st loop end 計算されるERI 値 (ss,ss) 1 個 (pp,pp) 81 個更新される G 配列要素 (ss,ss) 最多 6 箇所 (pp,pp) 最多 486 箇所 37

38 積分型 ERI 計算の複雑さは積分型次第 # used registers Shmem (bytes) Spill stores (bytes) Spill loads (bytes) (ss,ss) (ps,ss) (ps,ps) (pp,ss) (pp,ps) (pp,pp) ,708 2,332 レジスタ数が足りないレジスタスピル発生 38

39 Shmem の活用積分型 # used registers Shmem (bytes) Spill stores (bytes) Spill loads (bytes) (ss,ss) (ps,ss) (ps,ps) 62 4, (pp,ss) (pp,ps) 63 7, (pp,pp) 63 7, Shmem を使ってレジスタスピル量を削減他にも細かなチューニング 39

40 性能積分型 (ss,ss) (ps,ss) (ps,ps) (pp,ss) (pp,ps) (pp,pp) 実時間 (1コアに対する性能向上) CPU GPU 1 コア 4 コア Naïve カーネル分割 (1.0x) (3.7x) (5.4x) (1.0x) (3.2x) (1.0x) (3.0x) (1.0x) (3.1x) (1.0x) (2.9x) (1.0x) (3.0x) -- 更なるチューニング 10.5 (23.4x) (23.4x) (17.2x) (18.8x) (9.7x) (14.1x) (10.6x) (15.9x) (6.1x) 9.6 (1.3x) (6.8x) 7.6 (1.5x) 40

41 全体性能比較 (CPU vs GPU) 14.3 秒 1.16 秒 CPU(1core) GPU: 12.3x CPU GPU Core-i7 2600K 3.4GHz (1core) Intel compiler v12.1 (-O3) Tesla C2050 CUDA 4.2 Program Kyudai-HFR Input data: h16o8 (24 atoms) 41

42 各種データでの性能比較 (vs.1 コア ) 42

43 各種データでの性能比較 (vs.4 コア ) 43

44 将来のアクセラレータ活用のあるべき姿は? 44

45 GPU を手軽に使って性能が改善するか? GPU に向いている単純なコード数のディレクティブ挿エキスパートによるチューニング実装と比較して 40% 程度の性能コンパイルできないコードも存在 45

46 GPU に不向きとわれるアプリは本当に不向きなのか? 実装アルゴリズムを GPU 特性に合わせて直すことで CPU を大きく上回る性能を達成 GTX 580 性能 : 対 CPU(1core) で最大 21.2 倍対 CPU(4core) で最大 6.0 倍本トライアルで性能向上を達成できた理由理解し易いシンプルなコードの提供実装屋の存在 46

47 CPUvs.GPU CPU Memory (on-chip) Memory (on-chip) GPU 如何に上手く使うか? 如何に稼働率を高めるか? Control Calculation Control Calculation 如何に性能向上に活かすか? Memory Memory 47

48 アクセラレータ活用のあるべき姿 (1/2) GPU 化に向く部分と向かない部分はある依然としてアプリ屋と実装屋のギャップは大きいアクセラレータ活用のあるべき姿素性の良いアプリコンパイラがそこそこ使える向かないアプリアプリ屋と実装屋の協調 (Co- Design?) で多くを向くアプリに! 理解し易いシンプルなコード ( マシン非依存 ) アプリレベルの最適化に注アーキ依存な度最適化実装レベルの最適化に注アクセラレータ HW としての進化フィードバック性能解析 48

49 アクセラレータ活用のあるべき姿 (2/2) CPU(FatCore) と GPU(ThinCores) の併用どうしても GPU に向かない処理はある (ppp 型など ) ただし, データサイズがさく実時間が短いことが多いこのような処理は CPU に任せるタスク並列的な CPU/GPU 併用 49

Microsoft PowerPoint - GPUシンポジウム _d公開版.ppt [互換モード]

Microsoft PowerPoint - GPUシンポジウム _d公開版.ppt [互換モード] 200/0/9 数値流体解析の並列効率とその GPU による高速化の試み清水建設 ( 株 ) 技術研究所 PHAM VAN PHUC ( ファムバンフック ) 流体計算時間短縮と GPU の活用の試み現 CPUとの比較によりGPU 活用の可能性現 CPU の最大利用ノード内の最大計算資源の利用すべてCPUコアの利用適切なアルゴリズムの利用 CPU コア性能の何倍? GPU の利用の試み

HPC 分野におけるGPU 活用技術 アクセラレータ技術 WG 成果報告 SS 研アクセラレータ技術 WG 取りまとめ役井上弘士 ( 九州大学 ) 1

HPC 分野におけるGPU 活用技術アクセラレータ技術 WG 成果報告 SS 研アクセラレータ技術 WG 取りまとめ役井上弘士 ( 九州大学 ) 1