OpenCLプログラミングパラダイムは、異種コンピューティング向けのロイヤリティフリーのオープン標準になることを約束します。OpenCLに基づいたソフトウェアの開発に時間を投資すべきですか？長所短所？
回答:
質問は広すぎて曖昧すぎて、本当に答えられません。ただし、科学的コンピューティングの観点から、OpenCLに対する注目すべき点は1つありますが、これはめったに強調されません。これまでのところ、OpenCL用のオープンソースのインフラストラクチャライブラリを作成する努力はありませんでしたが、CUDAにはいくつかの優れたオプションがあります。
採用の主要な促進者は高品質でオープンなライブラリであるため、これはOpenCLを本当に傷つけると思います。
OpenCL対何？
質問がOpenCLとCUDAの場合、この質問について多くの手作業が行われていることがわかります。関係ありません。正直。カーネル-すべてのハード思考が行かなければならない-は、2つの言語間で実質的に同一です。お気に入りのエディター用のマクロを作成して、作業の99％を実行してOpenCLとCUDAの間を行き来できます。そうでなければなりません。最終的には非常によく似た種類のハードウェアを低レベルで制御します。{OpenCL、CUDA}で重要なカーネルを記述する方法を理解したら、それらを{CUDA、OpenCL}に移植するのは簡単です。
記述しなければならない定型的なホストコードも同様ですが、CUDAはシンプルなケースをシンプルに保ちます。それが私たちのセンターでCUDAを教える理由です。カーネルコードの作成にすぐに飛び込むことができますが、OpenCLのカーネル起動に関する説明のみを行う1日コースの1〜2時間を費やす必要があります。
しかし、そこでも違いはそれほど重要ではありません。より複雑なこと（複数のgpus上の非同期カーネル）を始めると、それらは両方とも同じように複雑になり、再び、一方から他方への行ごとの変換をほとんど行うことができます。
OpenCLとディレクティブベースのアプローチ（OpenACCまたはHMPPなど）の場合、これらはおそらく（願わくば）これらの種類のアーキテクチャをプログラミングする良い方法になるでしょう。作業の10％。しかし、どちらの選択肢が「勝つ」かはまだ分からないので、まだそれらとの作業に多くの時間を費やすことはお勧めしません。
ですから、CUDAとOpenCLの間では、あなたに都合の良い言語を選んで使用し、あまり心配しないでください。貴重な部分-問題を非常に少ないメモリで小さなコアの超並列SIMDコードに分解する方法を見つけること-は、プログラミングモデル間で非常に簡単に移植できるようになります。
NVIDIAハードウェアを使用している場合（おそらく使用している場合）、通常はCUDAをお勧めします。ライブラリについてのMatt Knepleyの主張はもう行き詰まっています。そうでない場合は、OpenCL。
OpenCLに基づいたソフトウェアの開発に時間をかけるべきかどうかは、あなただけが答えられる質問です。現在直面している問題を解決する可能性があり、他のオープンなソリューションでは解決できない可能性がある場合は、おそらく小さなプロジェクトを実装する際にリスクを取ることです。
それがうまくいけば、あなたはそれを標準化するのに十分な自信を築くか、他のソリューション（あなた自身の独自のソリューション、別のオープンソリューション、あるいは別の独自のソリューション）。
オープンソース運動についての素晴らしい事はためということであるあなたは、ソース持っているあなたは、必要に応じてプロジェクトをフォークするために必要なすべてを持っているし。コミュニティ自体が必要な機能を提供していなくても、それらの機能を自分で実装するのを止めるものは何もありません。また、これらの機能が必要な場合は、他のユーザーがそれらを必要とする可能性があるので、これらの変更をコアプロジェクトに貢献していただければ幸いです。
それだけでなく、自分の観点から改善すると、他の人にとっても改善され、独自の拡張機能を提出して、最終的にはすべての人にとってソフトウェアが改善される可能性があります。
最後に、はい、これはかなり一般的な質問に対するかなり一般的な回答です。より完全に答えるには、OpenCLに対するあなたの懸念を知る必要があります。成熟ですか？コミュニティサポート？使いやすさ？学習に必要な時間は？開発する時間ですか？手順を変更しますか？長所と短所について尋ねると、OpenCLと他のどの製品を比較しようとしていますか？すでにどのような研究を行っていますか？異種コンピューティング環境をサポートするために必要な機能は何ですか？
1つの大きなPROは、OpenCLの背後にあるベンダーの数です。NVIDIAを搭載したシステム用のかなり複雑なCUDAコードを開発するために多大な時間と労力を費やした研究グループに出会ったことがあります。コードが開発されてから1年後、研究グループはより大きくて高速なAMDベースのシステムにアクセスできましたが、コードを移植するための（人的）リソースがないため使用できませんでした。
CUDAとOpenCLのコア機能のセットがほぼ同じであっても（@JonathanDursiが指摘したように）、元の開発者がコードの変換タスクを割り当てられていない場合、移植プロジェクト全体に非常に時間がかかります。
ただし、CUDAとOpenCLの間には公式の非互換性があります。最も驚くべきことに、CUDAはc ++テンプレートをサポートしていますが、OpenCLはまだ公式にはサポートしていません。ただし、AMDは、テンプレートおよびその他のC ++機能をサポートするOpenCLの拡張機能を開発するための努力を行っています。詳細については、AMD dev centralのこの投稿をご覧ください。OpenCLの将来の改訂でこの作業が追加されることを期待しています。
この時点（2012年初頭）で、@ MattKnepleyがリンクする素晴らしいライブラリは、クローズドソースであるか、テンプレートを使用しているため、少なくとも当面はNVIDIA以外のハードウェアでは使用できなくなります。
GPUコンピューティングを学んでいる人にとっては、基本的なアイデアから学習者をそらす多くの詳細があるため、OpenCL Cは非常に難しいと言えますが、CUDAはよりシンプルで単純です。ただし、OpenCLにすべてのPythonシュガーをもたらすPyOpenCL（openclのPythonラッパー）など、OpenCLの学習と使用をより簡単にするツールがあります（PyCUDAもあることに注意してください）。たとえば、2つのアレイを追加するためのPyOpenCLデモは25行弱で、ホストとデバイスでのアレイの作成、データ転送、コンテキストとキューの作成、カーネル、カーネルの構築と実行方法が含まれています。 、GPUから結果を取得し、numpyと比較します（以下のリンクを参照）。
PyOpenCL- http: //mathema.tician.de/software/pyopencl
PyCUDA- http: //mathema.tician.de/software/pycuda
経験豊富なGPUプログラマーの場合、ここで@JonathanDursiに同意します。CUDAとOpenCLは基本的に同じであり、市長の違いはまったくありません。さらに、GPU向けの効率的なアルゴリズムを開発するという大変な作業は言語に大きく依存せず、ベンダーやドキュメントからのOpenCLサポートは2年前よりもはるかに成熟しています。違いを生む唯一の点は、NVIDIAがCUDAコミュニティへのサポートで本当に素晴らしい仕事をしているということです。
OpenCLには、CPU上で実行できるという追加の利点があり、IntelおよびAMDで既にサポートされています。そのため、利用可能なCPUコアを利用したい場合、アルゴリズムフレームワークを変更する必要はありません。CPUに最適化されたカーネルはGPUに最適化されたカーネルとは大きく異なる可能性があるため、OpenCLがシングルCPU /マルチコア指向のアプリケーションに最適なソリューションであるとは考えていません。ただし、私の経験では、CPUで実行できることからCODE開発にはメリットがあります。
OpenCLは現在、「チャンピオン」の不足に苦しんでいると思います。たとえば、今すぐNVIDIAサイトにアクセスすると（2011年12月16日）、スプラッシュページにGPUコンピューティングの科学的/産業的側面に焦点を当てた「Ken Burns Effect」スタイルのショットがいくつかあります。ナビゲーションオプションの4番目は、おそらくCUDAに到達する可能性のあるものを示しています。「GPUコンピューティング」サーバーおよびワークステーションを販売するメーカーは、NVIDIAソリューションを販売しています。
ATIの競合製品は一般的なAMDサイトと混ざっており、見つけるのが難しく、サードパーティのソリューションではあまり取り上げられていません。これらのソリューション、およびOpenCLベースのプログラミングを行う機能は確かに存在しますが、OpenCLプラットフォームの大企業のスポンサーはすでに「少なくとも私の心では、しかし私が話した他の人々の心では」フィールドを終了します」。たとえば、OS Xを使用している人々は、1年以内にAppleワークステーションが存在するかどうかについて推測するのに忙しすぎて、OpenCL GPUコンピューティングの推進に信頼を寄せることができません。
最も重要な要因は、CUDAがNVIDIAハードウェアのみでサポートされることです。
したがって、堅牢でポータブルなソフトウェアを作成する場合は、OpenCLが唯一のオプションです。せいぜい、現在CUDAで動作するいくつかのライブラリを中心に構築でき、将来的にはOpenCLを介してコードが引き出されることを期待しています。