CPU/GPUを協調利用するソフトウェア開発環境SPRAT

2009年6月24日
筑波大学計算科学研究センター
CPU/GPUを協調利用する
ソフトウェア開発環境
GPGPU研究会
佐藤功人（1）
滝沢寛之（1）
小林広明（2）
（１）東北大学大学院情報科学研究科
（２）東北大学サイバーサイエンスセンター
GPUを用いた汎用演算時代の到来
描画処理用プロセッサ（GPU）
・・・高いメモリバンド幅と浮動小数点演算性能
ピーク浮動小数点演算性能 [Gflop/s]
ピークメモリバンド幅 [GB/s]
汎用データ並列処理を高速化
2009/6/24
GPGPU講習会・研究会
2
GPUにおけるプログラミング環境
CUDA ・・・ NVIDIA社製GPU用プログラミング環境

GPUをコプロセッサとして利用

C言語を拡張したプログラミング言語（C for CUDA）

GPU内部の記憶領域や演算資源を柔軟に利用可能
CUDAによるソフトウェア開発

ハードウェアを意識したチューニングが必須

高い性能を達成するプログラム・・・ GPUに深く依存
2009/6/24
GPGPU講習会・研究会
3
CUDAにおけるソフトウェア開発の課題
特定計算機構成に特化したプログラムの問題

同一のプログラムの性能可搬性が喪失

搭載するGPUごとにチューニングが必要
理論性能
理論性能
実効性能
CPU
GPU
GeForce 8800 GTX
CPU
GPU
GeForce GTX 280
低効率
高効率
program
実効性能
program
CPU写真出典 www.kakaku.com
2009/6/24
GPGPU講習会・研究会
4
CPUとGPUを搭載する複合型計算機
複合型計算機（ヘテロジニアス型）

複合型・・・異なる種類のプロセッサを搭載

高いピーク演算性能・電力あたりの演算性能

ソフトウェア開発の難易度増加
CPU
GPU
1. プロセッサごとに異なるプログラミング環境
2. 計算機ごとに異なる最適な処理の割り当て
3. 演算条件ごとに異なる最適なプロセッサ
効率的な利用にはプログラミング支援が必要
2009/6/24
GPGPU講習会・研究会
5
1. プロセッサごとに異なるプログラミング環境
GPU・CPUのソフトウェア開発環境の違い

CPU ・・・ C, C++, FORTRAN等

GPU ・・・ CUDA, Brook+, OpenCL
GPUではベンダごとに開発環境が異なる

NVIDIA = CUDA/PTX
 AMD/ATI
= Brook+/CAL
・・・ベンダを超えた標準化の動き（OpenCL）
2009/6/24
GPGPU講習会・研究会
6
2. 計算機ごとに異なる最適な処理の割り当て
計算機ごとに異なる構成
2~4GB/s
PCI
express
・・・常にGPUが高性能とは限らない

高性能CPU + 低性能GPU

低性能CPU + 高性能GPU

性能比が不明な場合も・・・
データ転送オーバーヘッドの考慮
CPU
GPU
Max 25.6GB/s
Max 141.7GB/s
Main
Memory
Video
Memory

処理を担当するプロセッサの切り替え
・・・メモリ間でのデータ転送が必要（低速）

性能差が小さい場合に特に重要
2009/6/24
GPGPU講習会・研究会
7
3. 演算条件ごとに異なる最適なプロセッサ
LU分解の実効性能変化
演算条件への依存性
演算対象データ量などに依存して
CPU/GPUの優劣が変化
LU分解における例
CPU
Intel Core 2 Quad
Q6600 2.66GHz 1core
GPU
NVIDIA GeForce 8800GT
1200
実効演算性能 [Mflop/s]

1400

GPUの実行開始オーバーヘッドが大
・・・中～大規模演算で優位

実行時まで演算規模が定まらない
1000
800
600
400
200
CPU
0
0
2009/6/24
GPU
512
1024
行列サイズ [N]
GPGPU講習会・研究会
1536
2048
8
複合型向けのプログラミング支援
1. 計算機ごとに異なる最適な処理の割り当て
3. 演算条件ごとに異なる最適なプロセッサ
処理の割り当て支援・・・ Runtime Library
開発時
抽象化されたプロセッサに処理を割り当て
実行時
実際のプロセッサから最適なものを予測・選択
2. プロセッサごとに異なるプログラミング環境
統一的なプログラミング言語 + Compiler
・・・それぞれのプロセッサ用プログラムを自動生成
2009/6/24
GPGPU講習会・研究会
9
ソフトウェア開発環境 SPRAT
Stream Programming with Runtime Auto-Tuning
統一的なプログラミング言語
処理の自動割り当て
SPRAT
program
Unified Executable Code
with SPRAT Runtime
SPRAT Compiler
program
program
for CPU
（C++）
for GPU
（CUDA）
CPU
GPU
2009/6/24
Executable
Code
for CPU
Runtime
Compiler
Library
プログラムの
自動生成
Executable
Code
for GPU
実行時間予測機構
最適プロセッサ予測機構
プロセッサの
自動選択
GPGPU講習会・研究会
10
SPRAT言語とCompiler
プロセッサに依存しないプログラミング言語

プロセッサごとのプログラミング言語を隠蔽

処理の割り当てを意識せずにプログラミング可能
ストリームプログラミングモデルの導入

ストリーム・・・同じ処理を適用するデータ集合

カーネル・・・ストリーム要素に適用する処理を定義
入力ストリーム
SPRAT
program
SPRAT Compiler
program
program
for CPU
（C++）
for GPU
（CUDA）
CPU
GPU
出力ストリーム
カーネル
2009/6/24
GPGPU講習会・研究会
11
SPRAT言語による記述例
姫野ベンチマークにおける最内ループのカーネル関数化例
/ the main kernel of HIMENO Benchmark /
kernel map jacobi( gather stream<float> p,
in stream<float> a0, in stream<float> a1,
in stream<float> a2, in stream<float> a3,
in stream<float> b0, in stream<float> b1,
in stream<float> b2, in stream<float> c0,
in stream<float> c1, in stream<float> c2,
in stream<float> bnd, in stream<float> wrk1,
out stream<float> wrk2, out stream<float> gosa)
{
float ss, s0;
s0 = + a0*p[+1][ 0][
+ b0*( p[+1][+1][ 0]
+ b1*( p[ 0][+1][+1]
+ b2*( p[+1][ 0][+1]
+ c0*p[-1][ 0][ 0] +
0] + a1*p[ 0][+1][ 0] + a2*p[ 0][ 0][+1]
- p[+1][-1][ 0] - p[-1][+1][ 0] + p[-1][-1][ 0] )
- p[ 0][-1][+1] - p[ 0][+1][-1] + p[ 0][-1][-1] )
- p[-1][ 0][+1] - p[+1][ 0][-1] + p[-1][ 0][-1] )
c1*p[ 0][-1][ 0] + c2*p[ 0][ 0][-1] + wrk1;
ss = ( s0*a3 - p[0][0][0] )* bnd;
gosa = ss*ss;
wrk2 = p[0][0][0] + 0.8f *ss;
}
2009/6/24
GPGPU講習会・研究会
12
SPRAT言語と自動最適化
SPRAT言語・・・プロセッサに非依存

プロセッサ固有の最適化を記述できない

GPUではハードウェアを考慮した最適化が必要
CUDA言語に対する自動最適化機構
SPRAT
program
SPRAT Compiler
CUDA
Optimizer
・・・効果の大きい最適化手法を自動適用

再利用性のあるデータを高速メモリへ再配置

メモリアクセスの効率化
実効性能の向上
GPUごとの最適化の違いを吸収
2009/6/24
GPGPU講習会・研究会
C++
program
(for CPU)
CUDA
program
(for GPU)
13
SPRATコンパイラによる自動最適化の位置付け
ハードウェアを意識しない
最適化領域
通常の
ソフトウェア開発
SPRATの
ソフトウェア開発
CUDA言語
SPRAT言語
演算方法の検討
・冗長演算の削減
・乗算をシフト演算へ
2009/6/24
ハードウェアを意識したアプリケーション固有の
最適化領域
最適化領域
CUDA言語
コンパイラによる
自動最適化
CUDA言語
メモリアクセスの最適化アルゴリズムの検討
・効率的なメモリアクセス
・再利用性のあるデータを
高速なメモリに配置
GPGPU講習会・研究会
・データ配置の検討
・演算方法の変更
14
最適化1：プリフェッチ最適化
再利用性のあるデータを高速なメモリに配置
GPUにおける読み書き可能なメモリの特性
記憶容量
遅延時間
Global Memory
大（～1GB）
長（510 cycle）
Shared Memory
小（16KB）
短（36 cycle）
SPRAT言語の性質

Global
Memory
i-2 i-1 i i+1 i+2 i+3
i+20 i+21 i+22 i+23
再利用性の高いデータを
容易に抽出可能なように設計
i-2 i-1 i i+1 i+2 i+3 i+4 i+5
再利用性の高いデータを
Shared Memoryに配置
2009/6/24
Shared
Memory
i-1 i i+1 i+2 i+3
GPGPU講習会・研究会
15
姫野ベンチマークにおける自動最適化効果
演算サイズ：MIDDLE（256×128×128）
35
Sustained Performance [Gflop/s]

GeForce 8800 GTX SPRAT言語レベルでの
静的アライン調整
GeForce GTX 280
30
自動最適化
25
20
15
10
5
0
SPRATベース実装
2009/6/24
共有メモリへデータを配置共有メモリ + アライン調整
GPGPU講習会・研究会
16
最適化２：統合メモリアクセス化
非効率なメモリアクセスの効率化
GPUではデータアラインメントの影響が大きい

GeForce 8800 seriesでは実効メモリバンド幅に10倍の差
アラインされていないメモリアクセスを2回に分割して効率化
16N(m-1)
16N(m)
16N(m+1)
バイトアドレス
Global Memory
非アラインドメモリアクセス：低速
アラインドメモリアクセス：高速
N
スレッド群
Shared Memory
2009/6/24
GPGPU講習会・研究会
17
LU分解における自動最適化効果
3.0
実効演算性能比
2.5
GeForce 8800GTX
GeForce GTX280
2.74
2.04
2.0
1.5
1.29
1.16
1.0
0.95
0.82
0.5
0.0
統合メモリアクセス化
プリフェッチ最適化
2009/6/24
ー
ー
適用
ー
GeForce
GTX280
GeForce
8800GTX
ー
適用
適用
適用
GPGPU講習会・研究会
18
プロセッサの抽象化と自動選択

ストリーム処理プロセッサとして抽象化

実行時間履歴の記録と実行時間の予測
実行時間履歴
データベース
データ転送時間
予測機構
2009/6/24
SPRATから見える範囲
Stream
Processor
重み付け係数
CPU予測
実行時間
実行時間
予測機構
抽象度
Runtime Libraryによる実行時支援
GPU予測
実行時間
データ転送
時間
×
×
×
Runtime System
CPU優先度
GPU
優先度
最適プロセッサ
選択結果
予測機構
実行時間予測機構
最適プロセッサ予測機構
CPU
GPU
データ転送
オーバーヘッド
GPGPU講習会・研究会
19
実行時間履歴の記録と実行時間予測
自動プロファイリングと実行時間予測

各プロセッサで評価指標と実行時間の関係を記録

線形近似直線を引いて実行時間を予測

データ転送時間も同様の方法で予測
2. 実行時間予測
予測実行時間直線
実測点
2009/6/24
実行時間
実行時間
1. プロファイリング
予測実行時間直線
評価指標
評価指標
（例データサイズ）
（例データサイズ）
GPGPU講習会・研究会
20
自動選択のポリシー
実効性能指向で自動選択

予測実行時間をそのまま優先度として利用
実行時間予測機構
消費エネルギ指向で自動選択
GPU予測
実行時間

予測実行時間と消費電力を考慮した優先度

消費電力による重み付け
CPU予測
実行時間
×
×
重み付け係数
消費電力[W=J/s]
GPU
CPU優先度
CPUで処理した場合のエネルギ
CPU
CPU
GPU
2009/6/24
GPU優先度
GPUで処理した場合のエネルギ
予測実行時間[s]
GPGPU講習会・研究会
21
最適なプロセッサの予測
データ転送オーバーヘッドを考慮したプロセッサ選択

プログラムの周期性を想定

データ転送オーバーヘッド以上に優先度差が生じた場合に切り替え
プロセッサ間の優先度差 ≪ データ転送オーバーヘッド
累積優先度
データ転送オーバーヘッド
CPU
カーネル実行１回での比較
→ 切り替えが発生しない
GPU
CPU CPU CPU CPU CPU CPU CPU
GPU
GPU
GPU
GPU
データ転送オーバーヘッド
GPU
GPU
GPU
カーネル実行N回での比較
→ 切り替えが発生する
累積優先度差
2009/6/24
GPGPU講習会・研究会
22
GPU
CPU
切り替えまでの
オーバーヘッド
転送時間
カーネルの実行回数
累積優先度差
GPU vs CPU
累積消費エネルギ差
累積実行時間差
プロセッサを切り替えるタイミング
（GPU→CPUデータ転送オーバーヘッド）
累積優先度差
カーネルの実行回数
プロセッサ
切り替え
2009/6/24
GPU Switch
CPU
GPGPU講習会・研究会
23
LU分解による自動切り替え評価（１）
異なる構成の計算機で同じプログラムを実行

Core 2 Quad Q6600 + GeForce GTX 280
 Core 2 Quad Q6600 + GeForce 8800 GTX
 Core 2 Quad Q6600 + GeForce 8800 GT
実効性能指向で自動切り替え

評価指標・・・ Gflop/s （実効演算性能）
比較対象
CPU only ・・・ CPUのみを利用
 GPU only ・・・ GPUのみを利用
 SPRAT ・・・ CPU/GPUを自動切り替え

2009/6/24
GPGPU講習会・研究会
24
実効演算指向の自動選択
CPU + GeForce GTX280の場合
10000
Performance [MFLOPS]
9000
8000
7000
6000
5000
CPU only
GPU only
SPRAT
4000
3000
2000
1000
0
0
256
512
768
1024
1280
1536
1792
2048
Execution Size [N]
2009/6/24
GPGPU講習会・研究会
25
実効演算指向の自動選択
CPU + GeForce 8800GTXの場合
2000
Performance [MFLOPS]
1800
1600
1400
1200
1000
800
600
CPU only
GPU only
SPRAT
400
200
0
0
256
2009/6/24
512
768
1024
1280
Execution Size [N]
1536
GPGPU講習会・研究会
1792
2048
26
実効演算指向の自動選択
CPU + GeForce 8800GTの場合
Performance [MFLOPS]
1400
1200
1000
800
600
CPU only
GPU only
SPRAT
400
200
0
0
256
512
768
1024
1280
1536
1792
2048
Execution Size [N]
2009/6/24
GPGPU講習会・研究会
27
LU分解による自動切り替え評価（２）
異なる構成の計算機で同じプログラムを実行

Core 2 Quad Q6600 + GeForce GTX 280
 Core 2 Quad Q6600 + GeForce 8800 GTX
 Core 2 Quad Q6600 + GeForce 8800 GT
消費エネルギ指向で自動切り替え

評価指標・・・ Gflop/s/W （単位電力あたりの実効演算性能）
比較対象
CPU only ・・・ CPUのみを利用
 GPU only ・・・ GPUのみを利用
 SPRAT ・・・ CPU/GPUを自動切り替え

2009/6/24
GPGPU講習会・研究会
28
消費エネルギ指向の自動選択
CPU + GeForce GTX280の場合
Power Efficiency [Mflop/s/W]
35
30
25
20
CPU only
GPU only
SPRAT
15
10
5
0
0
256
2009/6/24
512
768
1024
1280
Matrix Size [N]
1536
GPGPU講習会・研究会
1792
2048
29
消費エネルギ指向の自動選択
CPU + GeForce 8800GTXの場合
Power Efficiency [Mflop/s/W]
8
7
6
5
4
3
CPU only
GPU only
SPRAT
2
1
0
0
256
512
768
1024
1280
1536
1792
2048
Matrix Size [N]
2009/6/24
GPGPU講習会・研究会
30
消費エネルギ指向の自動選択
CPU + GeForce 8800GTの場合
Power Efficiency [Mflop/s/W]
9
8
7
6
5
4
3
CPU only
GPU only
SPRAT
2
1
0
0
256
512
768
1024
1280
1536
1792
2048
Matrix Size [N]
2009/6/24
GPGPU講習会・研究会
31
まとめ
複合型計算機におけるソフトウェア開発の困難

プロセッサごとに異なるプログラミング環境

計算機ごとに異なる最適な処理の割り当て

演算条件ごとに異なる最適なプロセッサ
・・・性能可搬性の低下・プログラミング難易度の上昇
SPRAT （Stream Programming with Runtime Auto-Tuning）

プロセッサの抽象化と実行時自動プロセッサ選択機能

プロセッサに依存しないプログラミング言語
2009/6/24
GPGPU講習会・研究会
32
SPRATを利用する効果
プログラミング難易度の低下

処理の割り当てを考慮せずにプログラミング可能

特定のハードウェア構成を意識する必要が無い
プログラムの移植性・再利用性の向上

計算機構成に依存せずに最適なプロセッサを利用可能

ハードウェア依存の最適化を自動適用
演算条件の動的な変化への対応

与えられた演算条件で最良のプロセッサを自動選択
2009/6/24
GPGPU講習会・研究会
33
SPRATの今後
対応するプロセッサ構成の増加

現状・・・ CPU + NVIDIA社製GPU

将来・・・ AMD社製GPU, Cell B.E.等
自動選択機能の精度向上

実行時間予測の精度向上
ソフトウェア開発環境の整備・充実

デバッグツール・ライブラリ群などの整備
2009/6/24
GPGPU講習会・研究会
34
ご静聴ありがとうございました
2009/6/24
GPGPU講習会・研究会
35

Download Report