[論文レビュー] IPMACC: Open Source OpenACC to CUDA/OpenCL Translator

Ahmad Lashgar, Alireza Majidi+1 more|arXiv (Cornell University)|Dec 2, 2014

Parallel Computing and Optimization Techniques参考文献 9被引用数 10

ひとこと要約

IPMACC は、OpenACC 拡張 C/C++ コードを同等の CUDA や OpenCL コードに翻訳するオープンソースフレームワークであり、最適化されたデバイスバイナリを生成するためにシステムコンパイラ（例：nvcc）を活用する。パフォーマンスポータビリティを実現し、API 拡張やコードインスペクションをサポートする。また、OpenACC の抽象化が、手で最適化された CUDA に近いパフォーマンスにまで到達できない理由として、より高いカーネル起動オーバーヘッドと、より柔軟性に欠ける共有メモリ使用法が明らかになった。

ABSTRACT

In this paper we introduce IPMACC, a framework for translating OpenACC applications to CUDA or OpenCL. IPMACC is composed of set of translators translating OpenACC for C applications to CUDA or OpenCL. The framework uses the system compiler (e.g. nvcc) for generating final accelerator's binary. The framework can be used for extending the OpenACC API, executing OpenACC applications, or obtaining CUDA or OpenCL code which is equivalent to OpenACC code. We verify correctness of our framework under several benchmarks included from Rodinia Benchmark Suit and CUDA SDK. We also compare the performance of CUDA version of the benchmarks to OpenACC version which is compiled by our framework. By comparing CUDA and OpenACC versions, we discuss the limitations of OpenACC in achieving a performance near to highly-optimized CUDA version.

研究の動機と目的

• OpenACC と CUDA や OpenCL などの低レベルアクセラレータターゲットの間のポータビリティギャップを埋めること。
• 意味的同等性を保持しつつ、パフォーマンス解析を可能にする再利用可能なオープンソース翻訳パイプラインを提供すること。
• カーネル起動オーバーヘッドやメモリアクセスパターンの観点から、OpenACC と手で最適化された CUDA 間のパフォーマンストレードオフを評価すること。
• GPU アーキテクチャ上でニアオプティマルなパフォーマンスに到達できない原因となる、OpenACC の抽象化モデルの制限を明らかにすること。

提案手法

• フレームワークは4段階のコンパイルパイプラインを採用：前処理による構文およびスコープの正規化、OpenACC ディレクティブの抽出、OpenACC 構文を CUDA や OpenCL コードに翻訳、最後に nvcc や OpenCL コンパイラによる最終コンパイル。
• 構文正規化には uncrustify を活用し、OpenACC リージョンとその句を特定するためにカスタムの AST ベースのパーサーを用いる。
• 翻訳エンジンは、OpenACC のデータおよび並列化ディレクティブを、CUDA や OpenCL の同等構文にマッピングする。これにはスレッドブロックおよびグリッド構成、メモリ割り当て、データ転送が含まれる。
• 共有メモリ最適化は、データ再利用パターンを検出し、共有メモリコピー操作を挿入することで自動的に適用され、グローバルメモリアクセスが削減される。
• カーネル起動の削減は、ループのコalescing と、ループの独立性およびデータ依存関係の静的解析により、冗長な起動を最小限に抑えることで達成される。
• フレームワークは既存のツールチェーン（例：nvcc）と統合され、最終バイナリの生成が可能となり、本番環境での GPU 実行と互換性が保たれる。

実験結果

リサーチクエスチョン

• RQ1 正しくかつパフォーマンスを保持したまま、OpenACC コードを同等の CUDA や OpenCL コードに翻訳する効果はどの程度か？
• RQ2 特にカーネル起動頻度やメモリアクセスパターンの観点から、手で最適化された CUDA と比較して OpenACC が引き起こすパフォーマンスオーバーヘッドは何か？
• RQ3 OpenACC の抽象化は、共有メモリやコalesced メモリアクセスといった低レベル最適化の使用をどの程度制限するか？
• RQ4 この翻訳フレームワークを用いて OpenACC API を拡張したり、アクセラレータコードのパフォーマンスボトルネックを分析したりできるか？

主な発見

• パスファインダー・カーネルの OpenACC バージョンは、共有メモリベースの隣接ノード通信ができないため、CUDA と比較して顕著に高いカーネル起動オーバーヘッドを示し、起動頻度が高くなり、パフォーマンスが低下する。
• スパーキル低減異方的拡散（SRAD）ベンチマークでは、GPU ブロックレベルと CPU ブロックレベルの二段階削減戦略のおかげで、OpenACC が削減フェーズで CUDA を上回るが、これはメモリ転送コストの増加によって相殺される。
• 行列同士の積分野の CUDA バージョンは、OpenACC バージョンよりも 1.5 倍速く実行される。これは、カーネル起動回数が少なく、共有メモリによってより効率的なメモリアクセスが可能になっているためである。
• OpenACC が細粒度の共有メモリアクセスパターンを表現できないため、冗長なグローバルメモリアクセスと、特に高いデータ再利用を示すデータ並列カーネルにおいて、同期が増加する。
• Rodinia および CUDA SDK のすべてのベンチマークが意味的同等性を保ったまま正しく翻訳された。これは、多様なワークロードにおいて正しさが検証されたことを示している。
• OpenACC と CUDA 間のパフォーマンスギャップは、積極的なメモリ最適化を要するカーネルで最も顕著であり、パフォーマンスが重要なシナリオにおいて OpenACC の抽象化の制限が顕在化している。