Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie GPU-FPGA 協調計算を記述するためのプログラミング環境に関する研究（HPC169 No.10）
Ähnlich wie GPU-FPGA 協調計算を記述するためのプログラミング環境に関する研究（HPC169 No.10） (20)
GPU-FPGA 協調計算を記述するためのプログラミング環境に関する研究（HPC169 No.10）
- 1. GPU-FPGA 協調計算を記述するための プログラミング環境に関する研究 綱島隆太1、小林諒平2,1、藤田典久2、中道安祐未1 、朴泰祐2,1 1 筑波大学 システム情報工学研究科 2 筑波大学 計算科学研究センター 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会
- 2. 背景（HPC分野の動向） •アクセラレータがHPCにおけるランキング Top500 (2018/11)の上位 10機中7機に搭載されている –アクセラレータとは？ • コンピュータの演算速度を高めるための追加ハードウェア • 例：GPU、メニーコアCPU、FPGA –特に高い並列演算性能に加え電力効率の良さからGPUの搭載率が高い 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 1
- 3. 背景（GPUの欠点） 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 2 • 条件分岐 • データレベルの並列性が低い • 通信（データ交換、制御、リダクションのような処理） 欠点（GPUの苦手な処理） GPUの苦手な計算をFPGAにより高速化 • 宇宙物理分野におけるLocally Essential Tree (LET) 生成のFPGAオフロード – 計算+通信のオフロードにより、CPU実行に対し7.2倍高速化[Tsuruta, C. et al, 2015]
- 4. 背景（FPGA） •FPGA（Field Programmable Gate Array） –内部の論理回路を何度も再構成できる半導体チップ 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 3 • 回路の設計が自由 ⇨ 柔軟性が高い • データレベルの並列性が低い処理も高速化可能 – 並列化モデルがSIMDだけでなく、パイプラインも • CPUを介さずに他のFPGAと通信可能 ⇨ 高速通信 • （実装依存だが）GPUより省電力化が可能？ 利点 • GPUの苦手な処理をFPGAで実行 ⇨ さらなる高速化を目指す • これにはGPUとFPGAを相補的に活用できるプログラミング環境が必要 • 扱える問題の規模(リソース)に限りがある – 演算処理を直接回路化するため • 演算速度の絶対性能はCPU、GPUに敵わない – GPUとの連携を前提に活用 – 互いの欠点を補うように使う（相補的活用） 欠点
- 6. 現状のプログラミング環境 •OpenCL –ヘテロジニアスな並列計算機環境に対応したプログラミング言語 –GPU、FPGAにも対応 • FPGAではハードウェア記述言語（HDL）と比べ抽象化した記述が可能 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 5 • CUDAと比較してGPUの性能が出せない • CUDAよりも記述が複雑 • OpenCLによりFPGAで性能を出すにはかなりの知見が必要 – アプリケーションユーザーにとっては依然として高いプログラミングコスト • GPUとFPGAで並列化モデルが異なるため、それを考慮した記述が必要 問題点
- 7. 現状のプログラミング環境 •OpenCL –ヘテロジニアスな並列計算機環境に対応したプログラミング言語 –GPU、FPGAにも対応 • FPGAではハードウェア記述言語（HDL）と比べ抽象化した記述が可能 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 6 • CUDAと比較してGPUの性能が出せない • CUDAよりも記述が複雑 • OpenCLによりFPGAで性能を出すにはかなりの知見が必要 – アプリケーションユーザーにとっては依然として高いプログラミングコスト • GPUとFPGAで並列化モデルが異なるため、それを考慮した記述が必要 問題点 OpenCLによる統一的な記述 はデメリットが多い
- 8. 現状のプログラミング環境（続き） •CUDAとOpenCLの組み合わせにより、GPUとFPGAを一つのプロセス から利用する –我々はこの手法が実現可能であることを確認している[中道. et al, HPC168, 2019] –性能可搬性が OpenCL Only より高い 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 7 • それぞれ全く異なる言語で記述しなければならない – 2つの言語のプログラミングスキルが必要 – 並列度の指定方法がそれぞれ異なる • CUDA、OpenCL 両方のホストプログラムの用意が必要 – 記述量が膨大になりかなり負担が大きい • OpenCL自体の問題点は依然として残っている 問題点 CUDA OpenCL object object 実行 ファイル リンク 分割 コンパイル
- 9. OpenACC •OpenACC –アクセラレータへのオフロードを行うためのプログラミング規格 –OpenMPのようなディレクティブ形式の言語拡張 –複数種類のアクセラレータに対応することを想定している 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 8 • 指示文の挿入のみでオフロードが可能 – 移植性が高い • CUDA、OpenCLに比べて抽象度が高い – 簡潔に記述できる – 複雑だったプログラミングコストを大幅に減らせる • GPU での性能も高い 利点
- 10. OpenACCのアクセラレータ対応状況 •対応アクセラレータはコンパイラの実装次第 –GPU、メニーコアCPUに対応したものが市場向けに存在 • 特にPGI CompilerはNVIDIA社の傘下の企業が開発しており、CUDAに迫る性能を実現 –FPGAに対応したコンパイラにはOpenARC [Lee, S. et al., 2018] が存在 • 米国オークリッジ国立研究所（ORNL）で開発中 • 非公開であるが我々は共同研究により共有している 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 9 本研究ではOpenACCを用いた統一プログラミング環境を提案
- 11. OpenACCの複数アクセラレータ対応 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 10 #pragma acc parallel device_type(nvidia) num_gangs(200) device_type(intel) num_gangs(400) { … 一つのプログラム • 一つのプロセス内で同時に利用できるアクセラレータは一つ • OpenACCの規格自体が一度に複数の異なるアクセラレータの利用を想定していない – 一つのプログラム内でアクセラレータ毎に異なる並列度の指定をすることは可能 – どのアクセラレータを使うかは指定できない • アクセラレータ毎にオフロードする処理を割り当てる定義は存在しない 問題点 メニーコア CPUのみ利用 GPUのみ 利用 両方 同時利用
- 12. 提案手法 •本研究では既存のGPU、FPGA対応コンパイラを活用 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 11 –既存のコンパイラを利用できるよう 一つのプログラムを両アクセラレー タ向けに分割 • オフロード先は指定できるように定義を拡張 する • 既存のOpenACCファイルを利用できる形で –分割にはトランスレータを用いて ソースtoソースのコンパイルを行う –このトランスレータは本研究で新た に開発する • 理研と共同研究中の XACCコンパイラ[Tabuchi, A, et al., 2018]に実装予定 一つの GPU- FPGA 協調計算 実行 ファイル 一つの OpenACC プログラムソース GPU 演算 FPGA 演算 GPU向け ファイル FPGA向け ファイル OpenACC ソースファイル ❷ ❸ ❶ 一つのプログラムとして記述 ❷ トランスレータで分割 ❸ それぞれコンパイル＆リンク ❶
- 13. OpenARCでの両アクセラレータ利用 • OpenARCはGPU向け、FPGA向けコンパイルそれぞれに対応している • 複数の異なるアクセラレータの同時利用を想定していない • オブジェクトのリンクがうまくいかない – シンボルのコンフリクトが起こる – また、独自の環境変数により利用するアクセラレータを一つに定めなければならない • 上記の問題を解決するにはOpenARCの実装を大きく変える必要がある – ORNLにも確認 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 12 GPU向けには PGI Compiler の利用を検討
- 14. コンパイラの仕様 •OpenARC –言語はCのみ対応 –ソースtoソースコンパイラ • OpenACC → OpenCL for FPGA（ホストコードはC++） –OpenCLからFPGA書き込みファイルへの変換は Intel FPGA SDK for OpenCL をバックエンドで実行 •PGI Compiler –言語はC、C++、Fortranに対応 • 本研究では上記のOpenCL ホストコードとのリンクの都合上、C++を用いる –OpenACCから直接実行ファイルに変換 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 13 FPGA向けコンパイルに使用 GPU向けコンパイルに使用
- 15. コンパイルの流れ（全体） 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 14 int main() { ~~~~~~~~~~ #pragma acc ~~~=gpu ~~~~~~~~~~ ~~~~~~~~~~ #pragma acc ~~~=fpga ~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~ return 0; } openacc.c トランスレータで 利用デバイス毎に ２つのファイルに 分割 fpga. c gpu.c fpga.o gpu.o fpga.cl OpenACC オブジェクト ファイル a.out 実行ファイル fpga .aocx pgc++ fpga .cpp PGI Compiler (pgc++ -c) fpga .aoco aoc -c aoc g++ -cOpenARC OpenCL カーネル OpenCL ホスト 既存のコンパイラでコンパイル
- 16. 今回検証した部分 • トランスレータを除いた 部分を検証 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 15 OpenACC オブジェクト ファイル fpga.c gpu.c fpga.o gpu.o fpga.cl a.out 実行ファイル fpga .aocx pgc++ fpga .cpp PGI Compiler (pgc++ -c) fpga .aoco aoc -c aoc g++ -cOpenARC OpenCL カーネル OpenCL ホスト #pragma acc ~~~=gpu ~~~~~~~~~~ ~~~~~~~~~~ #pragma acc ~~~=fpga ~~~~~~~~~~ ~~~~~~~~~~ openacc.c トランス レータ
- 17. 実験1：実行ファイル生成の確認 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 16 OpenACC オブジェクト ファイル fpga.c gpu.c fpga.o gpu.o fpga.cl a.out 実行ファイル fpga .aocx pgc++ fpga .cpp PGI Compiler (pgc++ -c) fpga .aoco aoc -c aoc g++ -cOpenARC OpenCL カーネル OpenCL ホスト • トランスレータの出力を想定した2つ のOpenACCプログラムを用意 – 発表者が直接記述したもの • 2つのOpenACCプログラムから一つ の実行プログラムを生成可能か確認 – シンボル（関数、変数名）重複 ⇨ オブジェクトファイルのリンクが できない可能性 • 変数名の置き換え、最適化 (OpenARC) – 環境変数の重複 ⇨ 実行できない可能性
- 18. 実行したプログラム •GPUではベクトル加算、FPGAではデータコピー 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 17 FPGA側 GPU側CPU側 プログラム開始 GPUからデータを 転送 FPGAにデータを 転送し、 kernelをキック GPUでデータを 処理 GPUにデータを 転送し、 kernelをキック FPGAでデータ を処理 FPGAから データを転送 データの流れ #pragma acc data copyin(A[0:size], B[0:size]) copyout(D[0:size]) { #pragma acc kernels loop independent gang worker(16) for (i = 0; i < size; i++) { D[i] = A[i] + B[i]; } } GPU #pragma acc data copyin(a[0:size]) copyout(b[0:size]) #pragma acc kernels #pragma acc loop independent for (j = 0; j < size; j++) { b[j] = a[j]; } FPGA
- 19. 実験環境 • 筑波大学計算科学研究センター(CCS)の Pre-PACS version X (PPX)上で実験 – Cygnus(PACS X)は既に導入されているが、まだ利 用開始前だったためPPXを使用 – CygnusではGPU、FPGAが１世代新しい 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 18 ハードウェア構成 CPU Intel Xeon E5-2660 v4 x2 Host Memory DDR4-2400 16GB x4 GPU NVIDIA Tesla P100 x2 (PCIe Gen3 x16) FPGA Intel Arria 10 GX 1150 (BittWare A10PL4) (PCIe Gen3 x8) ソフトウェア構成 OS CentOS 7.3 GPU Compiler PGI Compiler 18.10 FPGA Compiler OpenARC V0.11 (Jan, 2018) Host Compiler GCC 4.8.5 OpenCL Compiler Intel FPGA SDK for OpenCL 17.1.2.304 1 010 1 0 PCIe 00 QPI
- 20. 実験1の結果 •オブジェクトファイル同士のリンクに成功 •実行ファイルが問題なく実行できることを確認 •CPU上で行った演算結果とGPU+FPGAで行った結果を比較 –等しいことを確認 •結果より –OpenACCのみでGPUとFPGA両方のプログラミングが可能 • ディレクティブ形式で統一した記述が可能に –PGI CompilerとOpenARCは組み合わせてコンパイル可能 • 最終的なFPGAのコードはOpenCLなので、OpenCLとOpenACCのリンクが可能なこともわかった 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 19
- 21. 実験2：性能比較 •本提案手法と既存の手法（CUDA+OpenCL）の性能比較を行った –予稿ではOpenCLとOpenACC(V0.11)の比較のみ •比較対象 –速度 –記述量 •OpenARCは最新版(V0.14)を入手し実験 –以前のバージョン(V0.11)ではリダクション演算、シングルワークアイテム実 行に対応していなかった • シングルワークアイテムはインテルが推奨 • 複数ワークアイテムの使用は性能低下の原因になりうる • 最新版ではこれらに対応 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 20
- 23. GPU-FPGA協調計算（続き） •FPGAでのCG法の補足 –疎行列圧縮にはCRS(Compressed Row Storage)を使用 –全過程をカーネルで実行 – r=b‒Ax の b にはGPUの計算結果を使用 –反復回数は1000回、非ゼロ要素数は219812 •全体で共通 –行列サイズは10974×10974 –単精度浮動小数点数 –実行環境は実験1と同じノード 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 22
- 24. コンパイル最適化オプション •以下を指定 –Tesla P100に最適化 •CUDA –--generate-code arch=compute_60,code=sm_60 –fast -O3 •PGI –pgc++ -ta=tesla,cc60 -O3 •OpenCL・OpenARC –ホストコードに –O3 を指定 –カーネルコードに最適化オプションは存在しない 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 23
- 25. 行列積（GPU） •CUDAではx,yのthread数16のほうが性能が高かったため16に指定 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 24 #pragma acc data copyout(c[:N*N]) copyin(a[:N*N], b[:N*N]) #pragma acc kernels { #pragma acc loop gang(N/32) vector(32) independent for (i = 0; i < N; ++i) { #pragma acc loop gang(N/32) vector(32) independent for (j = 0; j < N; ++j) { float sum = 0.0; #pragma acc loop reduction(+:sum) for (k = 0; k < N; ++k) sum += a[i * N + k] * b[k * N + j]; c[i * N + j] = sum; }}} OpenACC __global__ void matmul(float *a, float *b, float *c, int N) { int j = blockIdx.x * blockDim.x + threadIdx.x; int i = blockIdx.y * blockDim.y + threadIdx.y; if (i >= N || j >= N) return; int k; int l; int th=16; float sum = 0.0f; __shared__ float localA[16][16]; __shared__ float localB[16][16]; if(((j+1)/16 == N/16 && (j+1)%16 > 0) || ((i+1)/16 == N/16 && (i+1)%16 > 0)) th = N%16; for(l=0; l<N; l+=th) { __syncthreads(); localA[threadIdx.y][threadIdx.x] = a[i*N+(l+threadIdx.x)]; localB[threadIdx.y][threadIdx.x] = b[(l+threadIdx.y)*N+j]; __syncthreads(); for(k=0; k<th; ++k) { sum += localA[threadIdx.y][k] * localB[k][threadIdx.x]; }} c[i*N+j] = sum;} CUDA
- 26. 行列とベクトルの乗算（GPU） 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 25 #pragma acc data copyout(c[:N]) pcopyin(a[:N*N], b[:N]) #pragma acc kernels { #pragma acc loop independent gang(N/32) vector(32) for (i = 0; i < N; ++i) { float sum = 0.0; #pragma acc loop reduction(+:sum) for (j = 0; j < N; ++j) sum += a[i * N + j] * b[j]; c[i] = sum; } } } OpenACC matrix_vector_malti<<<dim3(N/16), dim3(16)>>>(d_c, d_vec_mul, d_vec_b, numdata_h); __global__ void matrix_vector_malti(float *a,float *b, float *c, int N) { int i = blockIdx.x * blockDim.x + threadIdx.x; int j; float sum = 0.0; if (i < N) { for (j=0; j<N; ++j) sum += a[i*N+j] * b[j]; c[i] = sum; } } CUDA
- 27. CG法のSpMV（FPGA） • SpMVのループは本来2重であるが、ネストを解いている – ネストしているとFPGAではパフォーマンスが大きく低下するため 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 26 #pragma acc data copyin(VAL[0:VAL_SIZE], COL_IND[0:VAL_SIZE], ROW_PTR[0:N+1], B[0:N], N, K, VAL_SIZE) copyout(X_result[0:N]) #pragma acc parallel num_gangs(1) num_workers(1) vector_length(1) { 〜 // 初期化計算 #pragma acc loop for(int i = 0; i < K; ++i){ temp_pap = 0.0f; int j = 0, l = ROW_PTR_local[0]; #pragma acc loop reduction(+:temp_pap, temp_sum) for(int m = 0; m < VAL_SIZE-ROW_PTR_local[0]; ++m){ temp_sum += p[COL_IND_local[l]] * VAL_local[l]; ++l; if(l == ROW_PTR_local[j + 1]) { y[j] = temp_sum; temp_pap += p[j] * temp_sum; temp_sum = 0.0f; ++j; l = ROW_PTR_local[j]; } } ... // 以降の計算 OpenACC __kernel __attribute((reqd_work_group_size(1,1,1))) void cg( __global float *restrict X_result, __global const float *restrict VAL, __global const int *restrict COL_IND, __global const int *restrict ROW_PTR, __global const float *restrict B, const int N, const int K, const int VAL_SIZE) { 〜 // 初期化計算 for(int i = 0; i < K; ++i){ temp_pap = 0.0f; int j = 0, l = ROW_PTR_local[0]; for(int m = 0; m < VAL_SIZE-ROW_PTR_local[0]; ++m){ temp_sum += p[COL_IND_local[l]] * VAL_local[l]; ++l; if(l == ROW_PTR_local[j + 1]) { y[j] = temp_sum; temp_pap += p[j] * temp_sum; temp_sum = 0.0f; ++j; l = ROW_PTR_local[j]; } } ... // 以降の計算 OpenCL
- 28. 実験結果（実行時間） •GPUではOpenACCの実行時間が 3.4倍になっている –OpenACCではシェアードメモリが利用 されていないと考えられる • CUDAでシェアードメモリを利用しない場合、 今回のOpenACCの結果の方が約2倍高速 • ディレクティブの挿入により簡単に高速化できる が、CUDAで手動チューニングした場合はCUDA の方が速いという結果 •FPGAではOpenACCが実行時間が 1.67倍伸びている 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 27 better 4664 7814 2094 7147 0 2000 4000 6000 8000 10000 12000 14000 16000 CUDA+OpenCL OpenACC msec GPU FPGA
- 29. 実験結果（記述量：行数） •空行、コメントを含まな い行数の比較 •行数ではOpenACCは CUDA+OpenCLに比べ 約30%削減 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 28 better 532 377 0 100 200 300 400 500 600 CUDA+OpenCL OpenACC 行数 約30% 削減
- 30. 実験結果（記述量：文字数） • ホストCUDA、ホスト OpenCLはホストコードの 関数 • OpenACCのカーネルGPU、 カーネルFPGAは OpenACCのディレクティ ブを含んだブロック内 • その他は変数の初期化、 バリデーション関数など • コメント、スペースは含 まない 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 29 5,502 5,830 1275 1268 399 511 6052 1104 0 2000 4000 6000 8000 10000 12000 14000 16000 CUDA+OpenCL OpenACC 文字数 ホストCUDA ホストOpenCL カーネルGPU カーネルFPGA その他 約半分まで 削減 better
- 31. 実験結果（記述量：文字数） •OpenACC では CUDA+OpenCL の 53%まで削減 •特にホストコードの削減 が貢献している –OpenCLはカーネル関数 の引数分だけ設定が必要 –カーネルが増えるとホス トコードの記述量も増え る 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 30 5,502 5,830 1275 1268 399 511 6052 1104 0 2000 4000 6000 8000 10000 12000 14000 16000 CUDA+OpenCL OpenACC 文字数 ホストCUDA ホストOpenCL カーネルGPU カーネルFPGA その他 約半分まで 削減 better
- 32. 実験2のまとめ • OpenACCとCUDA+OpenCLの性能比較を行った • OpenACCの方が記述量は少なく済んだがCUDAの方が高速だった – コンパイラによる自動最適化を見込んでいたが、ある程度の性能にとどまった – ディレクティブ指定の追加やコンパイラの最適化を考慮した書き換えによって改善が見込まれる • OpenCLの演算時間は1.67倍増加した – ただし以前のOpenARCより出力OpenCLにループアンローリングやネストの対策が見られた – 開発中のコンパイラであるため今後さらなる性能向上が期待される • 記述量は文字数は約半分、行数は約30%減った – OpenACCでもある程度のチューニングは必要 – しかし、CUDA+OpenCLのホストコードが膨大であるため開発者の負担は大きく減る – 主観であるが、記述量が減ったことで実際にデバッグの負担が減った 2019/5/10情報処理学会 第169回ハイパフォーマンスコンピューティング研究発表会 31