現状では、OpenACCを使うためには、Cray、CAPS、あるいはPGI(現在はNVIDIAの一部)のコンパイラを買う必要がある。なお、CAPSとPGIのコンパイラは無料のトライアルライセンスがあり、試してから買うということができる。
しかし、OpenACCの人気の高まりから、オープンソースの無料で使えるコンパイラの開発が始まっている。GTC 2014で発表のあった、gccでのOpenACCのサポートとヒューストン大学のOpenUHでのOpenACCサポートを紹介する。
エレクトロニクスCADの大手であるMentor Graphicsの組み込み部門は、組み込み用のLinuxなどを販売しており、gccなどのオープンソースへの貢献にも熱心な会社である。そのMentorが、2013年11月にOpenACCに加入し、gccでOpenACC 2.0をサポートする開発を行うことを発表した。
|
|
図1 gccでのOpenACCサポートに必要な開発 |
OpenACCをサポートするためには、gccでGPUコードを生成する必要があり、GPUという新しい命令アーキテクチャ(Instruction Set Architecture)に対応したバックエンドを開発する必要がある。また、OpenACCのディレクティブを解釈するフロントエンドを開発する必要がある。
現状では、OpenACCの入門編でも出てきた、図2に示すヤコビ法のソースコードがコンパイルできるところまで来ているという。
|
|
図2 OpenACCのディレクティブを挿入したヤコビ法のソースコード |
ただし、コンパイルできるというのは、ソースコードから、GPUにオフロードできるバイナリが一応作れるという意味で、図3に示すように、まだ、開発ができていない白で表示されていない部分や部分的な開発の薄い色の部分が多く存在する。特に、最適化はすべて未開発であるので、現在のコードの性能は期待できない。
|
|
図3 現在の開発状況 白の部分は開発ができていない部分。薄い色は部分的にできている部分 |
今後の予定であるが、2014年末にはgccとしてソースツリーに登録して公開できるようにすることを目指しているという。しかし、Linuxのディストリビューションに入るのは、もっと、時間がかかるという。なお、現在の開発対象OSはx86-64 Linuxだけで、アクセラレータはPTX3.1をサポートするNVIDIAのGPUだけである。
先行する商用コンパイラと比較して、どの程度の性能のコードが生成できるのかなど、未知数の部分も多いが、OpenACCの普及に観点からは、期待が大きい開発である。
ヒューストン大学はOpenUHという研究用のコンパイラを開発している。このコンパイラでOpenACCのサポートを開発している。研究のモチベーションは、OpenACCコードの性能はCUDAプログラムの性能とはギャップがあり、どのような最適化を行えば、この差を詰められるかを明らかにすることであるという。なお、現状での実装は、OpenACC 1.0で、図4に示したディレクティブをサポートしている。
|
|
図4 ヒューストン大学のOpenUHでのOpenACCサポート |
最適化の研究を目的としているので、gang、worker、vectorの各レベルを使い、NVIDIA GPUのグリッドやスレッドブロックの機能をフルに使おうとしている。
|
|
|
図5 最適化が研究の目的であるので、各種の並列ループスケジュールを行っている |
図6 カーネルループのスケジュール |
3重ループの場合の性能を、商用のコンパイラと比較したのが、次の図7である。Wave13ptとLaplacianという2つのプログラムで性能を比較しており、棒グラフは、左からOpenUH、PGI、CAPS、CRAYの実行時間[秒]となっている。なお、OpenUH、PGI、CAPSは同じハードウェアでの測定であるが、CRAYはCRAYのハードウェアでの測定であり、ハードウェアが違うので参考値である。
図7を見ると、3つのコンパイラで作ったコードの実行時間は、ほぼ同程度で、OpenUHがわずかに速いという結果になっている。
|
|
図7 3重ループのWave13ptとLaplacianの実行時間比較 |
次の3つの図は、NAS Parallelベンチマークを使った比較である。図8は、縦軸は秒で、NAS EPの棒グラフは左からOpenUH、PGIでParallel loopだけを使った場合、OpenUH、PGIでParallel loopとkernelの両方を使った場合、右端は参考値のCRAYの結果である。
また、NAS CGは、Parallel loopでOpenUH、PGI、CRAYを比較している。
|
|
図8 NAS EPとNAS CGの実行時間比較。A、B、Cは問題規模 |
NAS MGは配列の部分的コピーを多用するプログラムで、最大規模のCの場合、PGIとCRAYのコンパイラでは、メモリ不足となり実行できなかったという。
|
|
|
図9 NAS MGとSPの実行時間比較 |
図10 OpenUHのParallelとCombinedの実行時間比較 |
ベンチマークにより凸凹はあるが、OpenUHのコードの性能は、PGIやCAPSのコンパイラと十分に競争力のあるレベルになっている。
今後は、言語としてFortranのサポート、アクセラレータとしてIntelのXeon PhiやAMDのGPUのサポートを追加していく予定である。また、イレギュレーなメモリアクセスの場合の最適化など、一層の最適化を追加していく。
|
|
図11 今後は、Fortranのサポート、Xeon PhiやAMD GPUのサポートの追加、そして一層の最適化を行う予定 |
なお、このコンパイラはhttp://web.cs.uh.edu/~openuh/download/からアルファ版をダウンロードすることができる。
