まず、このスレッドを紹介してくれたAron Ahmadiaに感謝します。
科学コードのOpenCLに関して：OpenCLは低レベルAPIであるため、合理的な生産性を達成するために何らかの方法でこの機能をラップすることが重要です。さらに、いくつかの計算カーネルが関係するとすぐに、OpenCLカーネルとメモリハンドルをアプリケーション内で頻繁に渡す必要がある場合、コードが非常にダーティになる可能性があります。私はOCLToolsを知らないので、この点でそれらが有用であるかどうかは言えません。
ViennaCLについては、私はViennaCLの責任者であるため、最近図書館で働きました。:-)以下では、わずかに大きなスコープでのcuspとの比較のリクエスト、つまりViennaCLとCUDAベースの数学ライブラリcuspおよびMAGMAを扱います。（少なくとも私たちの側では）進行中の開発がたくさんありますが、現在の状態のみが考慮されます。
機能性。MAGMAは、通常の機能インターフェイスを介して、高密度マトリックスのBLAS機能を提供します。この機能のほとんどは、演算子オーバーロードおよびその他の構文糖を使用してViennaCL 1.2.0でも提供されます。
同じ3つの反復ソルバー（CG、BiCGStab、GMRES）がcuspとViennaCLで提供されます。前提条件のセットは著しく異なります：Cuspは対角、SA-AMG、およびさまざまなBridson前提条件を提供します。ViennaCLは、不完全LU分解、対角前提条件、最近のさまざまなAMGフレーバー、およびスパース近似逆条件を提供します。私の知る限り、すべてのカスプ前提条件はすべてGPUで実行されますが、ViennaCLは特にセットアップ段階でCPUベースの計算に依存します。現在、COO、CSR、DIA、ELL、HYBのように、スパースマトリックス形式の数はより多くなっています。一方、ViennaCL 1.2.0はCOOとCSRを提供します。
ViennaCLには、MAGMAまたはカスプの一部ではない多くの追加機能があります。構造化マトリックスタイプ（循環型、ハンケルなど）、高速フーリエ変換、並べ替えアルゴリズム（Cuthill-McKeeなど）、線形代数のラッパー他のライブラリの型。
パフォーマンス。ViennaCLのより多くの機能とハードウェアサポートは、通常、CUDAベースの実装と比較するとパフォーマンスが低下するという代償を伴います。これは、CUDAがNVIDIA製品のアーキテクチャに合わせて調整されているという事実にも一部起因しますが、OpenCLは、ある意味で、異なるメニーコアアーキテクチャ間の合理的な妥協を表しています。
全体的に、ViennaCLは現在、特にBLASレベル3でMAGMAよりも低速です。理由は、ViennaCLの異なる焦点（密な線形代数ではなく疎）、したがってMAGMAの高度な最適化です。特に、MAGMAでは現在、BLASレベル3の操作がかなり高速です。
同様に、cuspを使用すると、全体的なパフォーマンスがわずかに向上します。ただし、スパース行列演算は通常、メモリ帯域幅に制限があるため、データのセットアップなどと比較して、差はかなり小さく、ほとんど無視できます。前提条件とそのパラメーターの選択は、通常、スパース行列ベクトル乗算のパフォーマンスの違いよりも全体的な実行時間に大きな影響を与えます。
移植性。ハードウェアの移植性に関しては、ViennaCLはOpenCLのおかげで、すべての主要ベンダーのCPUとGPUを使用できます。対照的に、cuspとMAGMAは適切なNVIDIA GPUに依存しています。
ViennaCLはヘッダーのみで、幅広いC ++コンパイラーでコンパイルでき、GPUサポートが必要な場合にのみOpenCLライブラリとリンクする必要があります。原則として、ViennaCLの汎用アルゴリズムはOpenCLリンケージなしでも使用できますが、cuspとMAGMAはコンパイルのためにNVIDIAコンパイラーを、実行のためにターゲットシステム上のCUDAライブラリーを必要とします。MAGMAにはBLASライブラリも必要です。BLASライブラリは、新しいシステムを見つけたりインストールしたりするのに少し面倒な場合があります。
API。MAGMAは、BLAS機能用のBLASスタイルの関数インターフェイスを提供します。cuspのC ++インターフェイスもBLASの一部の関数を使用しますが、演算子のオーバーロードはありません。ViennaCLのほとんどのインターフェイスは意図的にBoost.uBLASに似ており、演算子のオーバーロードなどの構文糖を特徴としているため、ViennaCLはBoost.uBLASのように使用することも意図しています。したがって、定義済みの操作とアルゴリズムのセットを呼び出すだけでなく、非標準のアルゴリズムを使用する場合でも、純粋にCPUベースの実行からGPUコードへの移行を可能な限り簡単にすることを目指しています。専用のOpenCLカーネルが必要な場合、独自のOpenCLカーネルをViennaCLに統合するためのフレームワークもあります。したがって、ViennaCLはGPUに新しいアルゴリズムを実装するのに必要な時間が最小限に抑えられるという意味での高い生産性。これらの節約は、cuspおよびMAGMAと比較して、パフォーマンスのペナルティ（ある場合）を大幅に上回る可能性があります。（単体テストのスレッドでも、コード開発時間が科学の貴重なリソースであると述べられています。）
私の比較を通して、イデオロギーの問題（CUDA対OpenCL、BLASインターフェイス対演算子のオーバーロードなど）は確かに多くありますが、それらの議論は最初の質問の範囲を超えています。