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

1

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

WG設置の背景

3

エクサ実現へのチャレンジ• エクサ・フロップス級スパコンの実現における最大の課題は?
→「消費電⼒の壁」• 1EFlops@20MWスパコンを実現するには?
→「京」を基準にすると消費電⼒2xで性能100x1E+10Gflops (Rmax)

1E+09

1EFlops

100x

1E+08
1E+07

Top100@2011

2x

1E+06
1E+05
1E+04

100

1000

Power (KW)

10000

20MW

4

DARPA IPTO Exascale Computing Study
http://www.darpa.mil/tcto/docs/ExaScale_Study_Initial.pdf• 既存マシンをベースにしたスケーリングによりシステム性能を予測• 消費電⼒と⾯積（最⼤ラック数）制約を考慮
ノード名

説明

システム例

プロセッサ例

Heavy Node (HN)

高性能プロセッサ搭載型ノード

Red Storm

Intel, AMDなどのプロセッサ

Light Node (LN)

組込み向けプロセッサ搭載型ノードBlue Gene/L, /P

PPC440, 450

Aggressive Node (AN)1EFlopsのシステムを前提とした仮想ノード

無し

無し

5

DARPA IPTO Exascale Computing Study• 半導体デバイス– ITRS@2006• ノード消費電⼒モデル– Simplisticlly Scaled Power Model• プロセッサ→ITRS@2006• 主記憶（DRAM）→∝#DRAMチップ• ルータ→ベースと同じ 割合で一定• メモリ総容量– ∝理論ピーク性能– Fully Scaled Power Model• プロセッサ→ITRS@2006• 主記憶（DRAM）→∝#DRAMチップ×性能• ルータ→∝性能

コア

ラック

メモリ(DRAM) ルータ

Cacheプロセッサ

ノード

ボード

システム

6

DARPA IPTO Exascale Computing Study• 単純な量的変化だけではエクサ@2018は到達できない!
– Fullyで50〜60x，Simplisticallyで10xの性能向上が必要• 何らかの質的な変化が必要では?
– アクセラレーション技術

Figure 7.14: Light node strawman performance projections

1EFlops50〜60x

消費電力制約無し∞W Simplistically20MW Simplistically∞W Fully
20MW Fully

10x

LN: Light Nodeの結果
20187

本WGの狙い• 現在最も有望なアクセラレーション技術→GPU– 「GPU向きアプリ」を対象とした多くの事例報告• 素朴な，でも，本質的な疑問– GPUを「手軽に」使って性能が改善するか?

• PGIコンパイラを用いた「ライトな」チューニング– GPUに不向きと⾔われるアプリは本当に不向きなのか?
• GPUに不向きとして知られるアプリを対象に「ヘビーな」チューニング• 上記の調査を通して将来のアクセラレータ活用のあるべき姿を模索・議論
8

WG活動概要

9メンバーと活動内容
氏名

所属担当幹事

村上 和彰

九州大学

推進委員

⻘⽊ 尊之

東京工業大学

遠藤 敏夫

東京工業大学⿊川 原佳

理化学研究所

滝沢 寛之

東北⼤学

伊野 文彦

大阪大学

井上 弘士

九州大学

本田 宏明

九州大学

堀田 耕⼀郎富士通(株)丸山 拓⺒

富士通(株)

坂口 吉生

富士通(株)佐々木 啓

富士通(株)

久門 耕一(株)富士通研究所

成瀬 彰(株)富士通研究所

会合

日時

活動内容

第一回

2009年
10月29日(木) WG全体スケジュールの議論
 今後の議題検討

第二回

2010年
1月19日(火) 会員報告 (PGIアクセラレータコンパイラ、コーンビー
ム再構成の高速化、初心者によるGPUプログラミング
事例、複合型計算機向けソフトウェア開発環境)
 富士通報告 (GPGPUプログラミングの状況、GPUSIMから⾒たGPU)

第三回

2010年4月7日(水) 会員報告 (Linpack on GPU搭載スパコンTsubame) 富士通報告 (OpenCLの評価)
 OpenCLに関する議論

第四回

2010年
7月14日(水) 会員報告 (PGIコンパイラ評価)
 富士通報告 (nVidia新GPU評価)

第五回

2010年
12月3日(⾦)

 会員報告 (アクセラレータの大規模システム導入課題、Linpack on Tsubame2)

第六回

2011年
3月25日(⾦)

 会員報告 (PGIコンパイラ評価)
 富士通報告 (分子軌道法プログラムのGPU化検討)

第七回

2011年
8月19日(⾦)

 会員報告 (CUDA Fortran評価)
 富士通報告 (分子軌道法プログラムのGPU化結果)

第八回

2012年
1月19日(木)

 まとめ

10

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

3人の開発者による
PGIアクセラレータ利⽤事例• PGIアクセラレータ：– nVidia GPU向けのディレクティブ挿入方式のプログラム
開発言語・環境• 3人の開発者
開発者A

OpenMP・MPIによる並列プログラム開発経験はあるが，PGIアクセラレータの使用経験は無し．

開発者B

計算科学分野のアプリ開発経験は豊富．逐次プログラム開発が主体であり，プログラムの並列化はあまり詳しくない．

開発者C

並列処理のエキスパートであり，CUDA・OpenCLでのプログラム開発経験がある．

• 3種類のアプリ– 姫野BMT– 2D‑FDTD– 分子軌道法

12実験結果
姫野BMT
GFLOPS

Directive数

PGI ver.1

14.9

2⾏

PGI ver.2

19.2

CUDA版
(by 開発者Ｃ)

2D‑FDTD
開発工数

分子軌道法

GFLOPS

Directive数

1時間

18.5

10⾏

8⾏

+30分

…

…

…

…

50

…

数日

…

…

…

…

CUDA版
(by 開発者B)

…

…

…

45.5

…

3⽇程度

…

Xeon X5670
2.93GHz 1コア

3.9…

…

7.0

…

…

…

Xeon X5670
2.93GHz 4コア

7.8…

…

…

…

…

…

(学習に数日)

開発工数

GFLOPSGPUコード生成できずエキスパート（開発者C）のCUDA版実装と比較して40%程度の性能
13

GPUに不向きと⾔われるアプリは本当に不向きなのか?
14分子軌道法とは• 分子内において，主に電子がどのような運動をしており，どのようなエネルギーを持っているかを量⼦化学的計算により求める方法の一つ– 分子物性の解析– 創薬、新素材の開発– ex) プリンタのカラーインク、液晶ディスプレイ

15

GPUでの高速化は難しい「らしい」
分子軌道法プログラムの GPU 化は一般的に難しいとされている• 数例の報告のみ• オリジナルコード– コードが複雑、ステップ数大– PGI アクセラレータコンパイラのディレクティブの方法では、GPU へのオフロードコードは生成されず• GPU使用の問題点– 倍精度計算の使⽤– 開平逆数、指数関数計算が必要– 条件分岐計算– レジスタ量が不⼗分– シェアードメモリを利⽤のための適切な⽅法が不明確– デバイスメモリサイズの制限– などなど16分⼦軌道法プログラムの処理フロー
分子の座標、座標、電子数、基底関数データなどを入力
重なり積分S, １電子ハミルトン行列
Hcore、および、２電子積分を計算
重なり積分をCholesky分解（S=UTU）
密度行列の初期値（D0）を設定• 積分駆動型アルゴリズムによる２電⼦フォック⾏列計算• Obara のアルゴリズムによる積分計算法計算• 全てC言語で記述

密度行列と２電子積分から２電子ハミルトン行列Gを計算
密度行列を更新

F=Hcore+Gを計算
FC=SCεを解く
Cから新たな密度行列Dを計算

no

密度行列が収束した？
yes
収束したF, C, Dなどを用いて、望みの期待値（エネルギーなど）を計算

N

Nkl

Gij   Dkl [2 i j | kl  ik |  jl ]2電子積分計算（ERI）を含む
G行列計算式17

ボトルネックはG⾏列計算
CPUCore-i7 2600K
3.4GHz (1core)Compiler
Intel v12.1 (-O3)

ProgramKyudai-HFR

Input datah16o8 (24 atoms)

Elapsed time

分子軌道法プログラムの高速化≒ G⾏列計算の⾼速化

14.29 sec18

CPU向け並列化

19

G⾏列計算の概要＆OpenMPによるCPU向け並列化

係数⾏列作成1st 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
1st loop end

omp parallel for

1st loopのiterationをスレッドに分配
omp atomic

他スレッドと同じ箇所を更新する可能性
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種類の積分計算
係数⾏列作成1st loop begin
2 nd loop begin
3 rd loop begin
4 th loop begin
初期積分計算垂直漸化式計算
th4 loop endrd
3 loop end
水平漸化式計算G⾏列更新
2 nd loop end
1st loop end(ss,ss)タイプ(ps,ss)タイプ(ps,ps)タイプ(pp,ss)タイプ(pp,ps)タイプ(pp,pp)タイプ

CPU: Core‑i7 2600K 3.4GHz (1core)Compiler: Intel v12.1 (‑O3)
Program: Kyudai‑HFR
Input data: (H2O)8 (24 atoms)
Elapsed time: 14.29 sec

21

OpenMPによる並列化効果(コア数:1〜4)
CPU
Core‑i7 2600K
3.4GHz (1‑4 cores)

Compiler
Intel v12.1(‑O3 ‑openmp)

ProgramKyudai‑HFR
6種類の積分型を全てOpenMPで並列化

Input datah16o8 (24 atoms)

22

性能

実⾏時間（1コアに対する性能向上）
積分型(ss,ss)(ps,ss)(ps,ps)(pp,ss)(pp,ps)(pp,pp)CPUGPU

1コア

4コア

246
(1.0x)
279(1.0x)
122(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

GPU向け並列化（NAÏVE実装）

24

G⾏列計算処理 ((ss,ss)積分型)
係数⾏列作成1st 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
1st loop end

係数⾏列作成係数⾏列数：16種
総量：2.4MB (⼊⼒依存)
1st & 2 nd loop：
ループ回数：139,656 (⼊⼒依存)
ERI計算：
ループ回数：81 (⼊⼒依存)
ERI値：1種 (積分型依存)
G配列更新
前出ERI値と関連する部分を更新
G⾏列更新：6箇所 (積分型依存)
G配列要素数：1,596 (⼊⼒依存)(*) Input data: (H2O)8 →24 atoms
25

G⾏列計算のGPGPU化
係数⾏列作成1st loop begin
2 nd loop begin
3 rd loop begin
4 th loop begin
初期積分計算垂直漸化式計算4 th loop end
3 rd loop end
水平漸化式計算

1st & 2 nd loop：
ループ回数：139,656 (⼊⼒依存) 1st & 2 nd loopの各iterationを1スレッドに割当

G⾏列更新
2 nd loop end
1st loop end(*) Input data: h16o8 (24 atoms)

26

G⾏列計算のGPGPU化
係数⾏列作成1st loop begin
2 nd loop begin
3 rd loop begin
4 th loop begin
初期積分計算垂直漸化式計算4 th loop end
3 rd loop end
水平漸化式計算

ERI計算：
ループ回数：81 (⼊⼒依存)
ERI値：1種 (積分型依存) マルチスレッド化
 各ERI値の計算には5スレッド

使⽤（定量的な解析より）

G⾏列更新
2 nd loop end
1st loop end(*) Input data: h16o8 (24 atoms)

27ボトルネックはどこに?

係数⾏列作成1st 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
1st loop end

Nスレッド並列(*) N=2〜81

N‑1スレッドは待機（6回のatomic操作）(*) Input data: h16o8 (24 atoms)

28

G⾏列計算のGPGPU化
係数⾏列作成1st 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
1st loop end

部分G⾏列更新
ERI値毎に、関連する箇所を更新
G⾏列更新箇所：6(全要素数：1,596)
 更新箇所は不連続
 他スレッドが同時に同じG⾏列要素を更新する可能性
 atomicCAS()による排他処理CAS: Compare And Swap(*) Input data: h16o8 (24 atoms)

29

GPU環境(*) CC = CUDA Core

 Tesla C2050

Stream Multi-processor
Register Files (128KB)

Fermi世代

CCCCCCCC CUDA 4.2

CC
CC
CC
CC

CC
CC
CC
CC

CC
CC
CC
CC

CC
CC
CC
CC

CC
CC
CC
CC

CC
CC
CC
CC

CC
CC
CC
CC

L1+Shmem:64KB
(x14)

SM

SM

X-Bar
L2(128KB)
MemoryController
64bit
GDDR5(x6)

L2(128KB)
MemoryController
64bit
GDDR530

性能

実⾏時間（1コアに対する性能向上）
積分型(ss,ss)(ps,ss)(ps,ps)(pp,ss)(pp,ps)(pp,pp)

CPU

GPU

1コア

4コア

246
(1.0x)
279(1.0x)
122(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)Naïve45(5.4x)‑‑‑‑‑‑‑‑‑?

‑‑‑‑‑‑
31

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

ボトルネックはどこに存在する?
〜atomic操作を外すと…〜• CPU (1core)
246 ms• GPU (2x2x5)
45 ms (5.4x)• GPU (w/o atomic操作) 25 ms (9.8x)(*)ただし、正しい結果は得られない

ボトルネックはG⾏列計算のatomic操作→これをなんとかしないと速くならない!
33

Kernel分離：atomic操作を無くす！
1st & 2 nd loop begin

1st & 2 nd loop begin

ERI計算
分離

G⾏列更新
1st& 2 nd loop end

ERI値の計算直後に関連するG⾏列要素を更新

ERI計算(ERI値をメモリにWRITE)

1st & 2 nd loop end+

1st & 2 nd loop begin(ERI値をメモリからREAD)

G⾏列更新

1st & 2 nd loop end

ERI値をメモリに記録するオーバーヘッドは高いメモリバンド幅で隠蔽(と期待)34

性能

実⾏時間（1コアに対する性能向上）
積分型(ss,ss)(ps,ss)(ps,ps)(pp,ss)(pp,ps)(pp,pp)CPUGPU

1コア

4コア

246
(1.0x)
279(1.0x)122(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)Naïve

カーネル分割45(5.4x)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

10.5(23.4x)
16.2(17.2x)12.6(9.7x)6.3(10.6x)
10.1(6.1x)9.6(1.3x)

?
35

性能

実⾏時間（1コアに対する性能向上）
積分型

CPU
1コア

GPU
4コア

Naïve

246
66.2
45
(ss,ss)(1.0x)(3.7x)(5.4x)
279
85.8‑‑‑(ps,ss)(1.0x)(3.2x)
122
39.6‑‑‑(ps,ps)(1.0x)(3.0x)
67
21.3‑‑‑(pp,ss)(1.0x)(3.1x)• 積分型により性能UP率に⼤きな違い
62
21.0
‑‑‑
(pp,ps)• 複雑な積分型はGPUで性能向上難しい?
(1.0x)(2.9x)→さらなるチューニングを試みる!
12
4.0
‑‑‑
(pp,pp)(1.0x)(3.0x)

カーネル分割

10.5 GPU向き(23.4x) •繰り返し多•計算単純
16.2(17.2x)12.6(9.7x)6.3(10.6x)
10.1
GPU不向き(6.1x) •繰り返し少9.6 •計算複雑(1.3x)
36

積分型によるG⾏列計算処理の違い
係数行列作成1st loop begin
2nd loop begin
3rd loop begin
4th loop begin
初期積分計算垂直漸化式計算
4th loop end
3rd loop end
水平漸化式計算G行列更新
2nd loop end
1st loop end

計算されるERI値(ss,ss)1個(pp,pp) 81個更新されるG配列要素(ss,ss) 最多 6箇所(pp,pp) 最多486箇所
37

ERI計算の複雑さは積分型次第
積分型(ss,ss)(ps,ss)(ps,ps)(pp,ss)(pp,ps)(pp,pp)# usedregisters
54
6363636363

Shmem Spill stores Spill loads(bytes)(bytes)(bytes)000064640296
2200
164
136
0852
636
0
2,708
2,332

• レジスタ数が足りない→レジスタスピル発生
38

Shmemの活用
積分型(ss,ss)(ps,ss)(ps,ps)(pp,ss)(pp,ps)(pp,pp)# usedregisters
50
63
62
63
63
63

Shmem Spill stores Spill loads(bytes)(bytes)(bytes)
00
00
28
28
4,224
164
116
768
224
44
7,680
700
448
7,872
232
44• Shmemを使ってレジスタスピル量を削減– 他にも細かなチューニング

39

性能

実⾏時間（1コアに対する性能向上）
積分型(ss,ss)(ps,ss)(ps,ps)(pp,ss)(pp,ps)(pp,pp)CPUGPU

1コア

4コア

246(1.0x)279(1.0x)122(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)Naïve

カーネル分割45(5.4x)
‑‑‑
‑‑‑
‑‑‑
‑‑‑
‑‑‑

10.5(23.4x)
16.2(17.2x)12.6(9.7x)6.3(10.6x)
10.1(6.1x)9.6(1.3x)

更なるチューニング

10.5(23.4x)
14.9(18.8x)8.6(14.1x)
4.2(15.9x)9.2(6.8x)7.6(1.5x)40

全体性能比較(CPU vs GPU)
14.3秒

CPU
Core-i7 2600K
3.4GHz (1core)Intel compiler v12.1(-O3)

GPU
Tesla C2050
CUDA 4.21.16秒

ProgramKyudai-HFR

CPU(1core)GPU: 12.3x

Input data: h16o8(24 atoms)
41

各種⼊⼒データでの性能比較（vs. 1コア）

42各種⼊⼒データでの性能比較（vs. 4コア）

43

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

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

45

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

46

CPU

CPU vs. GPU
Memory(on-chip)

Memory(on-chip)

如何に上手く使うか?
如何に稼働率を高めるか?

Control

ControlGPU

Calculation

Calculation

如何に性能向上に活かすか?

MemoryMemory47アクセラレータ「活用の」あるべき姿（1/2）• GPU化に「向く」部分と「向かない」部分はある– 依然としてアプリ屋と実装屋のギャップは大きい• アクセラレータ活用のあるべき姿– 素性の良いアプリ→コンパイラが「そこそこ」使える– 向かないアプリ→アプリ屋と実装屋の協調（Co‑Design?）で多くを「向く」アプリに!
理解し易い
シンプルなコード（マシン非依存）アプリ・レベルの最適化に注⼒

アーキ依存な⾼度最適化

実装レベルの最適化に注⼒
フィードバック

アクセラレータHWとしての進化性能解析48

アクセラレータ「活用の」あるべき姿（2/2）• CPU(Fat Core)とGPU(Thin Cores)の併用– どうしてもGPUに向かない処理はある（pppp型など）– ただし，データサイズが⼩さく実⾏時間が短いことが多い– このような処理はCPUに任せる• タスク並列的なCPU/GPU併用

49