コンパイラ、そしてもっと：アクセラレーター・プログラミング

Michael Wolfe, PGI

SC13が終わって、ひとつの熱い問題は、次世代HPCシステムをプログラムするための、標準的なアプローチの選択である。保証はできないが、これらのシステムは、マルチコアCPUにある種のアクセラレーターが取り付けられたノードの大規模なクラスターになるであろう。標準的なプログラミング・アプローチは、開発者と特にISVを確信させるために、来たるべき世代のシステムに備えて、採用を始める必要がある。John Barr氏は、Scientific Computing Worldの最近の記事において、より哲学的な視点から、同じ問題を提起した。そこで私は、より技術的に深い展望から、この問題について述べる。

現在のHPCプログラミングの多くは、ノードにまたがるMPIを使うフラットMPI、あるいは、ノード内のコアが共有するメモリーを使うOpenMPとMPIのハイブリッド並列を使っている。フラットMPIの長所は、より単純なプログラミング・モデルと、1レベルの並列性と、1種類のAPIだけから成ることである。これは短所でもある。同じノード内のデータを共有せず、全てのランクがメッセージとバッファを管理するからである。MPI+OpenMPは、上記の長所と短所を逆にする。

過去20年間、MPIとMPI+OpenMPがとてもうまくいった理由は、命令セット、ノードのトポロジー、パフォーマンス・プロフィールに何らかの違いがあっても、大部分のHPCシステムがだいたい同じ仕組みだったからである。これらのシステムは、ノードのネットワークであり、ノードは1つ以上のプロセッサーを備え、プロセッサーは1つ以上のコアを備える。ノード上のコアは、仮想的かつ物理的なメモリーを共有する。そして、ハードウェア・キャッシュ・コヒーレンシーによって、共有メモリー・プログラミングを比較的安全にする。大規模な共有メモリー・システムを持つSGI製マシンのような、少数の例外がある。それには、特定のアプリケーションのためのプログラミング・モデルと性能の長所がある。

John氏はたぶん正しいだろう。しかし、私はコメントを加えたい。10年後のHPCシステムがどのような物になるのか解らない。近い将来のHPCシステムがどのようになるのかさえ解らない。普通のMPI+OpenMPプログラミング・モデルは、とてもよく貢献したが、私は「シンプル」と言うことを躊躇する、今から5年から10年後の最新のデザインに、うまく適応できないであろう。なぜならば、均一なネットワーク、ノード、コア、メモリーという仕組みが変わりそうだからである。HPCはもうひとつの曲がり角にいる。それをもたらすのは、経済的要素と技術的要素による。

技術は、ゆるやかに性能を上げていくために、より遅いコアのより高い並列度を推進している。並列度には３種類ある。古典的なマルチコアまたはマルチプロセッサーによる、スレッドまたはタスクの並列。古典的なベクトル演算は、SIMDとして作り直される。マルチスレッドは、おもにメモリー・レイテンシーであるレイテンシーが大きな複数の演算を重ね合わせる(overlap)。システムに充分なバンド幅が内蔵され、マルチスレッディングが可能ならば、あるスレッドがキャッシュ・ミスによってストールしている間に別のスレッドが実行可能になって、よくできたアプリケーションはピーク性能に近い結果を出す。バンド幅の増大は、レイテンシーの削減よりは容易であるが、無料できることではない。

HPCの経済的要素は、可能な限り、最高かつコモディティーな部品の利用を要求する。高級なワークステーションはいまだに重要ではあるが、ベンダーは、モバイル機器が成長し、そこに重点的に投資すると予想できる。幸運なことに、モバイル機器の部品は、低価格、低消費電力、かつ高性能の必要がある。例え痛みを伴うとしても、ワークステーション用の部品からモバイル機器用の部品への移行は有益な可能性がある。

しかし重要なことは、このようなシステムがどのように見えるか、我々には正確には予想できず、かなりの変化がありそうなことである。いくつかのシステムは、高性能で高価なコアをプロセッサーそれぞれに搭載する、今日のシステムのように見えるだろう。別のシステムは、組み込みシステムの影響を受けた低消費電力チップを使うであろう。Blue Gene L/P/Q、Intel ATOM/Quark、ARMを考えてみよう。ノード内並列度と、複数のノードにまたがる並列度の比率は異なる。

多くのシステムにはアクセラレーターがある。NVIDIAとAMDのGPU、Intel Xeoi Phiのメニーコア、他にTI DSP。アクセラレーターの種類によって、並列化のスタイルは異なる。

今日のアクセラレーターのメモリーは、物理的にも論理的にも、ホストのメモリーと別である。これは、変わっていくだろう。アクセラレーターとホストが同じアドレス空間を共有する動きがある。それは、ある種の共有メモリーを許す。しかし、リモート・アクセスあるいはソフトウェアに制御された分散共有メモリを使っても使わなくても、より遠くのメモリーへアクセスには、性能のペナルティーがまだある。古典的なTreadmarksシステムのように。特に、今日のアクセラレーターは、広帯域のメモリーと合わせて設計される。ホストメモリーが同じ帯域幅を提供できないならば、性能が犠牲になるだろう。ホストとアクセラレーターが同じ物理メモリーを共有しても、同じことが真実である。今日のラップトップPCでは、しばしばプロセッサー・チップ自体が統合されたグラフィックス機能(IGU)を持っている。IGUは、グラフィクス・バッファーのために、システム・メモリーを使う。これは、電子メールやプレゼンテーションのような、大部分の小規模な用途にとっては充分である。しかし、双方向ゲームのような挑戦的なグラフィック・アプリケーションにとっては、統合チップセットではなく、独立したGPUとVRAMが望ましい。例えばハイブリッド・メモリー・キューブのような将来の記憶サブシステムは、広帯域共有メモリーを可能にして、バランスを変えるかもしれないが、我々がコストを支払う気があればの話である。

そこで、Jorh Barr氏は、現在、明日、そしてこれから数十年に可能になる様々なシステムについて、満足な性能を出すために、どのような言語でプログラムを書くべきか、提案を試みた。それぞれの提案について議論しよう。

MPI + OpenMP 3.1

OpenMP 3.1は、OpenMP 3.0のマイナー・チェンジであり、3年間の開発期間を経て2011年にリリースされた。均一なコアと均一な記憶アクセスからなる小規模なノードに対して、OpenMPはとても役立つ。C、C++、Fortranよりも高水準の言語を使うのでない限り、OpenMPに代わる何かが必要であると主張することは難しい。しかし、それらの言語さえ、ネイティブの並列要素を採用し始めている。Fortranは、以前から配列代入と「forall」構文を持っていて、ベクトル計算機あるいはSIMD並列を表現でき、現在は「do concurrent」構文と「subsumming」がOpenMP並列「do」のような働きをする。CとC++については、OpenMPに似たスレッド並列あるいは「Cilk」型タスク並列について、言語委員会による議論が現在進行している。ありがたいことに、言語委員会はゆっくり動いているが、これらの議論が尽きれば、OpenMP指示行の必要性は減るだろう。

長所：OpenMP 3.1は、比較的高水準であり、完全に成熟している。これは、基本的に、全てのマルチコアまたはマルチプロセッサー・システムにサポートされる。必ずしもスケーラビリティーはないが、機能と性能に優れた移植性を与えている。

短所：既存のプログラムをマルチコアへ移植する際に、誰でもOpenMP並列ループの単純さを好むが、すべての並列ループに指示行をつける必要性を嫌っている。OpenMP 3.1モデルのシステムは少し古い。現在および将来のシステムは、もはやそれほど均一ではない。OpenMPは長時間走る並列スレッドに依存し、このことは実行モデルに影響し、プログラミング・モデルで明らかになる。私の考えでは完全にエレガントであるが、OpenMPは現在タスクを持ち、タスク・モデルはスレッド・モデルに融合した。

移植性：言及されるように、HPCに今日使われているすべてのマルチプロセッサとマルチコアシステムによって、OpenMPはサポートされている。コアの数が少ない共有メモリー・マルチコア環境全体で、かなり良いコストパフォーマンスと移植性が得られる。しかし、OpneMP 3.1は、ヘテロジニアスあるいはアクセラレーター付きのシステムをサポートしない。Purdue大学による印象的な研究プロジェクトがあり、Nvidia GPUの上で若干のコンパイル時および実行時の労力によって、OpenMPを実行した。彼らには、試作コンパイラーによるベンチマーク・プログラムについてめざましい結果がある。しかし、それはまだ研究段階であり、アクセラレーター・プログラミングにおいて最も性能に影響する部分を隠すか仮想化するために、犠牲を強いられる。

将来：OpneMP 4.0には、ヘテロジニアスなシステムのためと、データと計算のローカリティーによる利点をよりよく制御するための機能が追加される。並列システムのより複雑な世界の制御に適応するために、言語はより複雑になっている。結局のとこと、今から10年以上経てば、ベースとなる言語が充分な並列性をサポートして、OpenMP指示行は不要になるかもしれない。

MPI + CUDA：

CUDAはGPUスタイルのアクセラレーターのより低水準のプログラミング・モデルである。3次元のグリッドとブロック、ソフトウェアに制御されるキャッシュ、シェアード・メモリー、SIMDスタイルによるブロック内隣接スレッドの実行のような、GPUの構造的な特徴が、明示的に現れる。正しい方法で人生を捧げた(dedicated)開発者が使えば、GPUの全ての力を出し切れることが、CUDAモデルと言語の特徴である。しかし、これは挑戦的なプログラミング・モデルで、GPUに移植するために多くの投資が必要となる。その上、GPUの世代が変わるたびに、高度にチューニングされたCUDAカーネルを、新しいハードウェアのために再チューニングするためのコード維持費が発生する。

さらに、CUDAは現在唯一のベンダーであるNVIDIA専用の解決策である。PGIはx86 CPU上で動くCUDA-X86を開発したが、GPU用と比べて性能は悪い。他のGPUのためのCUDAを想像する人はいるが、私はそのような開発のためのヒントを見たことがない。

長所：CUDAツールキットは、5年ほどの歴史があり、枯れている。これを使えば、GPUの全てをプログラマーが制御できる。デバッグと性能測定のためのツールも、NVIDIAが提供している。GPUが進化すると言語とプログラミング・モデルも進化する。CUDA-Fortranは、Fortranプログラマーに同じプログラミング・モデルを提供し、より高水準な言語機能もある。

短所：CUDAは低水準のプログラミング・モデルである。C/C++/Fortranで書かれた既存のアプリケーションをCUDAへ移植するためには、大規模なソースコードの書き換えが必要であり、並列計算に適さないアルゴリズムとデータ構造を変更する必要がある。

移植性：CUDAは現在NVIDIA製GPU専用である。CUDAをCPUで並列に動かそうという努力があった。CUDA-X86はその技術のいくらかを利用する。これらの労力は、まれに大成功することもあるが、CUDAプログラミングは、マルチコアとSIMD並列性を持つCPUに必ずしも適応しない。さらに、ある世代のNVIDIA GPUにチューニングされたカーネルは、次世代のGPUのために、スレッド・ブロックの大きさと形状、ループのアンローリングなどを、再チューニングする必要がある。

将来：NVIDIAは、CUDAを開発し、サポートし続ける。CUDAは、GPUプログラミングの重要な役割の中で、特に性能が重要なライブラリーやアプリケーション・カーネルのように、投資が性能に結びつく部分で、重要な役割を演ずるだろう。

MPI + OpenCL：

OpenCLは、CUDAと同様に、基本的にGPUスタイルのアクセラレーターのためのプログラミング・モデルである。これは、GPUの特徴を明示的に書く必要があるが、NVIDIA専用の言語ではない。DSP、x86、ARMさえ含む多くのターゲットにサポートされている。CUDAと同様に、プログラマーによるアクセラレーターの完全な制御が可能である。CUDAとは異なり、OpenCLコンパイラーはホスト・コードを生成しない。プラットフォームAPIは、完全にライブラリーによる実装であり、特に小さなプログラムについては、非常に冗長にさえみえる。カーネルを起動する方法によって、CUDAとOpenCLの違いが明らかになる。CUDA Cにおいては、カーネルの起動は、手続き呼び出しに、グリッドとブロックの指定が追加された構文である。

kernel<<< gridsize, blocksize >>>( arg0, arg1, … );

CUDAコンパイラーは、この構文を、引数を管理するライブラリー呼び出しと、実際のカーネル起動に変換する。OpenCLには、そのようなコンパイル機能が無いので、引数を管理するためのライブラリー呼び出しと、カーネル起動のためのライブラリー呼び出しが必要になる。

clSetKernelArg( kernel_handle, 0, sizeof(arg0), &arg1 ); clSetKernelArg( kernel_handle, 1, sizeof(arg1), &arg1 ); … clEnqueueNDRangeKernel( queue_handle, kernel_handle, 1, NULL, &globalsize, &localsize, 0, NULL, NULL );

この違い以外、OpenCLプログラミングは、CUDAプログラミングと同じくらい、潜在的に強力である。

OpenCLが実装された広い種類のターゲットがあるため、OpenCLの性能と移植性に関する議論が、過去数年間にあった。試しに、「OpenCL performance portability」を好きな検索エンジンで調べてみなさい。HPCwireの最近の記事は、可能な全てのアーキテクチュアについて別々にあるいは同時に、ヘテロジニアス・コンピューティングが可能になるので、OpenCLに賛成している。私は、その記事の大部分に同意する必要がある。その記事に、性能と移植性について、次のように書かれている。「事実、アーキテクチュアAの上で最高の性能を得るために、カーネルの新しい版を各必要があるかもしれない。しかし、それは我々が望むことではないか？」この文で最も重要な単語は他でもなく「カーネル」である。組み込みシステムの世界で、一人の開発者は、例えばビデオ処理、音声エンコーディング、その他の一つのカーネルに集中するであろう。そのシナリオでは、それぞれのアーキテクチュアのために、一つのカーネルをチューニングしては、またチューニングできる。しかし、何十年もの寿命を持つ何百万行ものコードを持っているならば、このような方法は生産的でない。

長所：カーネルはCUDAと同様に明示的なプログラミング・モデルで書かれる。そして、OpenCLは広い範囲のターゲットにサポートされる。

短所：全てのデバイスに共通な開発ツールがないので、デバッグとプロファイリングは、時として泥沼である。言語は進化しているが、進化は遅く、言語を設計する意思がある委員会が存在しない。

移植性：プログラミング・モデルがより低水準であるので、ターゲット・アーキテクチュアの特徴を利用してカーネルを書く必要がある。すなわち、異なるターゲットのために、カーネルを再チューニングするか、書き直す必要がある。

将来：OpenCLモデルは、組み込みシステムあるいはモバイル市場を狙っており、そこでは、アプリケーション開発者にとって、必ずしもターゲット装置の詳細が必要ではない。この分野では、動的なjust-in-timeコンパイルが重要である。HPC分野では、並列計算機の全てのノードで実行するたびにカーネルを再コンパイルすることは、オーバーヘッドになる。しかし私は、投資による成果が充分に見合う場所で、OpenCLがCUDAと同様にアクセラレーター・プログラミングの重要な役割を演ずると予測する。

MPI + OpenACC：

OpenACCは、CPU+アクセラレーターシステムをターゲットとする、指示行(ディレクティブ)ベースのプログラミング・モデルで、わざとOpenMPに似せている。OpenMPがマルチコア・システムのために働くように、OpenACCはアクセラレーター・システムのための働く。OpenACCでは、性能のペナルティーなしにシステムの特徴を隠せるか仮想化できる部分は、そのようにし、残りの部分はプログラマーが明示的に書く。例えば、プログラミングと実行のモデルは、ホストCPUとGPUが別々のメモリーを持つことを意識する必要があり、ホストとデバイスの間でのデータ移動も意識してプログラムを書く必要がある。しかし、OpenACCは、変数の名前空間をホストとGPUの間で共有し、オーバーヘッドなしに、同じ変数名についてのホストとデバイス間のデータ転送を仮想化する。当初の意図では、OpenACCをOpenMPに合併するはずだったが、2つのグループは異なるアプローチを決定した。隠さずに書くと、本稿の著者は、OpenACC言語委員会のキーメンバーで、以前OpenMP言語委員会に参加していた。
OpenACCは、注目していたアクセラレーターの上で、並列アルゴリズムを高速に実行することに注目して設計された。今日、アクセラレーターは、大きな数の、マルチコア、ベクトル、あるいはSIMD並列性を必要とする。これは、逐次コードに適していない。逐次コードは、常に、より高速なホストCPUの上で効率よく動く。これが、CPUとアクセラレーターを密結合したシステムに対するプログラミング・モデルの主要な動機付けである。そして、これは、完全なアプリケーション全体で性能を最大にするために、おそらく最も効率的である。

長所：OpenACCは複数の種類のデバイスをサポートし、性能の移植性にいくつかの最初の証拠がある。

短所：OpenACCは比較的若い。そして、全ての機能を使えるオープン・ソースの実装がまだない。また、今のところ、ホストCPUのマルチコアをターゲットとする実装がないので、OpenMPと併用する必要がある。いくつかの重要な機能は、まだ開発中である。そして、どのように機能が実装されているかの違いにより、ベンダー間の互換性に問題がある。

移植性：OpenACCはアーキテクチュアの多くの要素を仮想化できるので、異なる種類のターゲットについてプログラムが同様にうまく動くべきである。性能の移植性について、初期的な証拠はあるが、納得できる証拠はまだ無い。

将来：OpenACC 2.0はリリースされたばかりであり、重要な機能を追加する作業が続いている。OpenACCを使ってGPUへ移植された多くのアプリケーションがあり、そこからの経験が言語設計と実装にフィードバックされている。これからの数年間、ホストCPUだけでなくアクセラレーターをターゲットとする、商用とオープンソースの両方の実装について、刺激的な研究を予想できる。

MPI + OpenMP 4.0 Target指示行

OpenACCがなぜOpenMPとこれほど異なるのか、尋ねられるかもしれない。ちょっとGPUの上でOpenMPを実行してみないか。これは、良い質問で、重要な点である。私は、数年前に記事でこの質問に答えようとした。GPUを使って並列性能が良いプログラムを実装するためには、避けるべきいくつかの制約と、利用すべきいくつかの可能性がある。

OpneMP ARBは、バージョン3.1からちょうど2年後の大きな改訂である、バージョン4.0をリリースした。多くの新機能のひとつは、「device」構文である。OpenMPのデータ管理のための「target data」と「target update」構文は、OpenACCの同様の構文に対応する。OpenMP委員会は、並列性の新しいレベルを、古典的なOpenMPスレッド即ち「team」に加えることを選んだ。OpenMP 3.1において、並列実行領域はすスレッドのチームによって実行され、並列実行ループの反復とタスクは、1つのチームに含まれる複数のスレッドによって共同作業される。OpenMP 4.0「device」構文においては、複数のスレッドから1つのチームを作り、複数のチームから1つの「league」を作成できる。複数のチームの追加は、
GPUのような全てのスレッドに対するバリア同期をサポートしないデバイスのためである。この追加には、2つの不幸な副作用がある。第一に、既存のOpenMPプログラムをGPUのようなデバイスに移植する作業は、単に並列ループの前後に指示行を加えるだけでは済まず、簡単ではない。OpenACCと同様に、プログラマーはデバイスのデータ・トラフィックを管理する必要がある。しかし現在、同様に新しい種類の並列性を追加する必要がある。第二に、例えばIntel Xeon Phiのような若干のデバイスについては、並列性の新しいレベルは不要で、おそらく欲しくないだろう。OpenMPは、そのようなターゲットに最適化できる。これは、ひとつのターゲットのためのチューニングが、もうひとつのターゲットのためのチューニングとかなり異なるかもしれず、性能の移植性に挑戦することを意味する。OpenMP委員会が解決が難しいいくつかの決定をしたことを、私は心配する。

Intelは、OpenMP 4.0をサポートするデバイスを作る主要な支持者で、おそらくXEON Phiコプロセッサーのために仕様準拠の実装をする。Texas Instrumentsも、いくつかのARM+DSPヘテロジニアスSoCについて、サポート計画を表明した。Conveyの新しいMX計算機は、OpenMP 4.0に適合するハイブリッドOpenMPをサポートする。Crayは、XEON PhiとKeplerアクセラレーターを含む彼らの製品について、OpenMPを用意する計画を発表したが、性能の移植性について約束はしていない。他のOpneMPベンダー・メンバーは、まだ「device」構文に対するサポートを発表していない。

長所：完全なOpenMPを実行できるデバイスに、既存のOpenMPプログラムを移植するためには、4.0 「device」構文を含むOpenMP 4.0は、より単純な方法のように見える。データ転送を管理する必要性はあるが、これはどのプログラミング・モデルでも同様である。

短所：OpenMPを実行するように設計されていないターゲットについて、良い性能を得られるかどうか、明らかでない。「team」構文の試作版はまだ実装されていない。性能の移植性は、OpenCLと同様に、言語の正しい方向への一歩ではあるが、挑戦的課題である。現在の4.0「device」構文は、まだ完全に規格化されていなくて、より慎重な定義が必要である。

移植性：移植性についてはもっと早く述べるべきだったが、将来の多種多様なアクセラレーター・アーキテクチュアのために性能移植性を実現するためには、OpenMP「device」構文があまりに規範的である( prescriptive)と、私は心配する。それぞれのターゲットのために、プログラマーが別々のプログラムを書くことになれば、この言語は長所の多くを失う。

将来：OpenMP 4.0は、まだ新しくて、「device」構文の他に多くの新機能がある。いくつかの成熟した実装例を得るまでに、時間を要するであろう。OpenMPグループは、並列プログラミングの範囲全体について、より迅速な調査と採択に専念しているようである。「device」構文は、拡大されるか、ターゲットに対処するために収縮される必要があるだろう。OpenMP「device」構文がホストCPUだけでなく、DSP、メニーコア、GPUについても良い性能を出せる場合に限り、この言語は選択に価するであろう。

他に何か：

大企業が推進しているというだけの理由で重要な残り2つのヘテロジニアス・プログラミング言語について、Jorh Barr氏は言及しなかった。Google Renderscriptは、カーネル計算モデルを使って、OpenCLカーネルとバッファーのようなメモリ・アロケーションを管理する。OpenCLとは異なり、Renderscriptは、グラフィックスのようなデータ構造にアクセスするカーネルのために最適化される。すなわち構造体の長方形配列である。OpenCLまたはCUDAでは可能な、ランダムにインデックスされる種類のアドレスを得るのはかなり難しい。実行時には、CPUまたはGPUのような、どのような適切なデバイスを使ってでもカーネルを実行できる。そして、その装置でのアクセスが要求されるように、データを移動する。Microsft C++AMP (Accelerated Massive Parallelism)は、かなり高水準なC++に特有の解決案である。C++のテンプレートとラムダ関数を使って、洗練されたプログラマー、おそらく全てのC++プログラマーは洗練されている、のために、データ移動と計算をする。これは、非常に高機能な「paralell_for_each」関数を導入し、それによって計算領域とカーネル関数を並列領域(parallel domain)全体に渡って作用させる。RenderscriptとOpenCLのように、実行時に記憶の移動を管理する。ホストとGPUのどちらでカーネルを実行するべきか、実行時に決められる。少なくとも1つの実験的な実装がRedmondにあるが、現在Microsoftだけがサポートしている。

結論：

来たるべきHPCシステムのためのツールとプログラミングの方法論は、アーキテクチュアの進歩に応じて、変わるだろうと、Jorn Barr氏は主張した。高水準で移植性があるヘテロジニアス・プログラミングの戦略は、この進化の初期の段階で、多くのユーザーを引きつける。MPIよりも前に、いくつかのメッセージ交換ライブラリーがあり、一部分はベンダー特有だった。MPIによる解決は、ソースコードを書き換えることなしに、クラスター・アーキテクチュア全体にアプリケーションを移植することを可能にし、ベンダーがアーキテクチュアの実装レベルでの革新に集中できるようになった。と同時に、革新はメッセージ交換ライブラリーの内部に限られた。OpenMPの前に、マルチプロセッサー・ワークステーションとクラスターのノード内のプログラミングのために、いくつかの高水準ディレクティブと、低水準のスレッディング・ライブラリーが存在した。同様にOpenMPを受け入れることによって、ソースコードを書き換えること無しに、マルチコア・アーキテクチュア全体に移植が可能になり、ベンダーがアーキテクチュアの実装レベルで革新に集中できるようになった。と同時に、プログラミング言語レベルでの革新を制限した。

ヘテロジニアス・プログラミングについては、我々は高水準プログラミングの戦略に同意したい。それは、できる限りターゲットに依存しないべきである。特に、異なるターゲットのために、異なるプログラムを書くことを、ユーザーに要求してはならない。同様に、低水準のプログラミングも必要であり、CUDAとOpenCLはこの要求を適切なデバイスにうまく適合させると、我々は同意する。高水準で、明らかに可能性がありのは、OpneACCまたはOpenMPである。最終的な選択に、ユーザーが行う。OpenMP「device」構文が成熟し、多種多様なデバイスのすべてで性能を移植できるプログラミングがサポートされるならば、これは現実的な選択肢になり得る。OpenACCが移植性とより一般性を示せるならば、選択肢になるべきである。2つの仕様が統合される望みがまだある。結局、それぞれの言語がどの程度使いやすく、最も重要な点として、いろいろなターゲットと性能移植性をサポートするかによって、ユーザーが選択するであろう。