首先，我要感谢 Aron Ahmadia 将我指向此线程。

至于科学代码中的 OpenCL：OpenCL 是一种低级 API，因此以某种方式包装此功能以达到合理的生产力至关重要。此外，一旦涉及多个计算内核，如果 OpenCL 内核和内存句柄需要在应用程序中大量传递，代码就会变得非常脏。我不知道 OCLTools，因此我不能说它们在这方面是否有用。

至于 ViennaCL：我是 ViennaCL 的负责人，所以我最近在图书馆工作。:-) 在下文中，我将在稍大的范围内处理与 cusp 进行比较的请求，即 ViennaCL 与基于 CUDA 的数学库 cusp 和MAGMA。仅考虑当前状态，即使有很多正在进行的开发（至少在我们这边）。

功能性。MAGMA 通过常用的函数接口为密集矩阵提供 BLAS 功能。ViennaCL 1.2.0 还使用运算符重载和其他语法糖提供了大部分功能。

cusp 和 ViennaCL 提供了相同的三个迭代求解器（CG、BiCGStab、GMRES）。预调节器集显着不同：Cusp 提供对角线、SA-AMG 和各种 Bridson 预调节器。ViennaCL 提供不完全 LU 分解、对角预条件子，以及最近各种 AMG 风格和稀疏近似逆预条件子。据我所知，所有 cusp 预处理器都完全在 GPU 上运行，而 ViennaCL 在设置阶段尤其依赖于基于 CPU 的计算。目前，稀疏矩阵格式的数量在风口浪尖较多：COO、CSR、DIA、ELL、HYB，而ViennaCL 1.2.0提供了COO和CSR。

ViennaCL 提供了许多不属于 MAGMA 或 cusp 的附加功能：结构化矩阵类型（Circulant、Hankel 等）、快速傅里叶变换、重新排序算法（例如 Cuthill-McKee）和线性代数包装器来自其他库的类型。

表现。与基于 CUDA 的实现相比，ViennaCL 中更大的功能集和硬件支持通常以较低的性能为代价。这也部分是因为 CUDA 是针对 NVIDIA 产品的架构量身定制的，而 OpenCL 在某种意义上代表了不同众核架构之间的合理折衷。

总体而言，ViennaCL 目前比 MAGMA 慢，尤其是在 BLAS 3 级。原因是 ViennaCL 的侧重点不同（稀疏而不是密集线性代数），因此 MAGMA 的优化程度更高。特别是 BLAS 3 级操作目前在 MAGMA 中要快得多。

同样，cusp 总体上提供稍好的整体性能。然而，由于稀疏矩阵运算通常受内存带宽限制，因此与数据设置等相比，差异要小得多并且通常可以忽略不计。预处理器及其参数的选择通常比稀疏矩阵向量乘法中的任何性能差异对整体执行时间的影响更大。

便携性。至于硬件可移植性，ViennaCL 可以使用所有主要供应商的 CPU 和 GPU，这要归功于 OpenCL。相比之下，cusp 和 MAGMA 依赖于合适的 NVIDIA GPU。

ViennaCL 是纯头文件，可以在各种 C++ 编译器上编译，如果需要 GPU 支持，则只需与 OpenCL 库链接。原则上，ViennaCL 中的通用算法也可以在没有任何 OpenCL 链接的情况下使用，而 cusp 和 MAGMA 需要 NVIDIA 编译器进行编译，并需要目标系统上的 CUDA 库来执行。MAGMA 还需要一个 BLAS 库，有时在新系统上查找或安装它会有点麻烦。

应用程序接口。MAGMA 为 BLAS 功能提供 BLAS 风格的功能接口。cusp 的 C++ 接口也使用了 BLAS 中的一些函数，但没有运算符重载。由于 ViennaCL 中的大多数接口有意与 Boost.uBLAS 相似，并且具有诸如运算符重载之类的语法糖，因此 ViennaCL 也打算像 Boost.uBLAS 一样使用。因此，除了调用一组预定义的操作和算法之外，我们的意图是尽可能简单地从纯基于 CPU 的执行过渡到 GPU 代码，即使要使用非标准算法。在需要专用 OpenCL 内核的情况下，ViennaCL 中还有一个用于集成您自己的 OpenCL 内核的框架。因此，ViennaCL 的目标更多的是从某种意义上说，在 GPU 上实现新算法所需的时间被最小化，因此生产率很高。与 cusp 和 MAGMA 相比，这些节省可以大大超过任何性能损失（如果有的话）。（在单元测试的帖子中也提到代码开发时间是科学中的宝贵资源。）

在我的比较过程中，肯定存在许多意识形态问题（例如 CUDA 与 OpenCL、BLAS 接口与运算符重载），但它们的讨论超出了最初问题的范围。

可以使用 OpenCL，但是缺乏基础设施，例如重要的成熟标准数学库，带有经过调整的事实上的标准线性代数组件，以及在某种程度上很好的分析工具，尽管后一个问题对于 GPU 有显着改善。这在今天的 CUDA 中可用，并且可以为 Nvidia 通过这种编程模型取得成功做出贡献。然而，OpenCL 似乎正在迎头赶上（缓慢地）。

今天，作为 GPU 编程的起点，CUDA 很好，如果需要，没有什么可以阻止使用 OpenCL 作为替代方案，例如使代码更便携。本质上，相同的内核代码可以在 CUDA 和 OpenCL 中使用，因此从 CUDA 到 OpenCL 应该不是主要问题。自己的经验证实了这一点。从性能的角度来看，可以使用相同的优化技术，并且对于琐碎的并发代码编译器应该可以很好地完成工作（例如循环展开等）。