Answers:
首先，我要感谢Aron Ahmadia指出我这个话题。
至于科学代码中的OpenCL：OpenCL是低级API，因此以某种方式包装此功能以达到合理的生产率至关重要。而且，一旦涉及多个计算内核，如果需要在应用程序中大量传递OpenCL内核和内存句柄，则代码可能会变得非常肮脏。我不知道OCLTools，因此我不能说它们在这方面是否有用。
至于ViennaCL：我是ViennaCL的负责人，所以我最近在图书馆工作。:-)在下面，我将在更大的范围内处理与cusp进行比较的请求，即ViennaCL与基于CUDA的数学库cusp和MAGMA进行比较。即使有很多正在进行的开发（至少在我们这边），也仅考虑当前状态。
功能性。MAGMA通过通常的功能接口为稠密矩阵提供BLAS功能。ViennaCL 1.2.0还使用运算符重载和其他语法糖提供了大多数此功能。
尖峰和ViennaCL都提供了相同的三个迭代求解器（CG，BiCGStab，GMRES）。预处理器的集合明显不同：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）和线性代数的包装器其他库中的类型。
性能。与基于CUDA的实现相比，ViennaCL中更多的功能和硬件支持通常以降低性能为代价。这也部分是由于CUDA是针对NVIDIA产品的架构量身定制的，而OpenCL在某种意义上代表了不同的多核架构之间的合理折衷。
总体而言，ViennaCL目前比MAGMA慢，尤其是在BLAS 3级。原因是ViennaCL的关注点不同（稀疏而不是稠密的线性代数），因此MAGMA的优化程度更高。特别是在MAGMA中，BLAS 3级操作目前要快得多。
同样，尖点总体上可以提供更好的整体性能。但是，由于稀疏矩阵运算通常受存储器带宽的限制，因此与数据设置等相比，差异明显较小，并且通常可以忽略不计。预条件器及其参数的选择通常对总执行时间的影响要比稀疏矩阵矢量乘法的任何性能差异大。
可移植性。关于硬件的可移植性，感谢OpenCL，ViennaCL可以使用所有主要供应商的CPU和GPU。相比之下，风口浪尖和MAGMA则依赖于合适的NVIDIA GPU。
ViennaCL仅是标头，可以在各种C ++编译器上进行编译，并且仅在需要GPU支持的情况下才需要与OpenCL库链接。原则上，也可以在没有任何OpenCL链接的情况下使用ViennaCL中的通用算法，而cusp和MAGMA需要使用NVIDIA编译器进行编译，并需要在目标系统上执行CUDA库。MAGMA还需要一个BLAS库，有时在查找或安装到新系统上可能会有些麻烦。
API。MAGMA为BLAS功能提供BLAS样式的功能接口。cusp的C ++接口还使用了BLAS的某些功能，但没有运算符重载。由于ViennaCL中的大多数接口有意类似于Boost.uBLAS，并且具有语法糖（例如运算符重载），因此，ViennaCL也应像Boost.uBLAS一样使用。因此，除了仅调用一组预定义的操作和算法外，我们的目的是使从纯基于CPU的执行向GPU代码的转换尽可能简单，即使要使用非标准算法也是如此。在需要专用的OpenCL内核的情况下，还有一个框架可以将自己的OpenCL内核集成到ViennaCL中。因此，ViennaCL的目标更多从最大限度地减少在GPU上实施新算法所需的时间的角度来说，生产率高。与风口浪尖和MAGMA相比，这些节省可以大大超过任何性能损失（如果有）。（在单元测试的线程中也提到过，代码开发时间是科学中的宝贵资源。）
在整个比较过程中，肯定存在许多意识形态问题（例如CUDA与OpenCL，BLAS接口与运算符重载），但是他们的讨论超出了最初的范围。
可以使用OpenCL，但是缺少基础设施，例如，重要的成熟标准数学库，具有经过调整的事实上的标准线性代数组件，并且在某种程度上具有良好的性能分析工具，尽管后者的问题对于GPU而言已得到显着改善。到目前为止，CUDA中已有此功能，并且可以通过此编程模型为Nvidia的成功做出贡献。但是，OpenCL似乎正在（逐渐）赶上。
今天，作为GPU编程的起点，CUDA很好，并且如果需要的话，没有什么可以阻止使用OpenCL作为替代，例如使代码更易于移植。本质上，相同的内核代码可以在CUDA和OpenCL中使用，因此从CUDA到OpenCL并不是主要问题。自己的经验证明了这一点。从性能的角度来看，可以使用相同的优化技术，并且对于琐碎的并发代码编译器应该可以很好地完成工作（例如，循环展开等）。