(免责声明:我是JavaCL和BridJ的作者)
除了基于JNA的版本之外,JavaCL还有一个功能齐全的BridJ端口,该端口完全在BSD下授权(因为BridJ本身就是BSD许可的)。
FYI BridJ提供比JNA低得多的每次调用开销,接近JNI性能,同时仍然非常便携(它目前发布Windows,Linux和MacOS X的32位和64位二进制文件,但其他平台正在计划中)。
但是,低级绑定的性能并不是唯一需要考虑的事项。虽然JavaCL和JOCL的面向对象API看起来很相似,但你必须照顾好额外的好东西。我不知道JOCL,但JavaCL附带:
- Java 类路径或任何 URL 中文件的透明#include
- 程序二进制文件的自动透明缓存
- 减少实用程序
- 线性代数效用
- 一个随机数生成器(一个库,而不是一个演示!
- 一个不错的GUI,可以在几秒钟内尝试图像转换内核
- 一个 maven 插件,它解析 OpenCL 内核(在 src/main/opencl 中找到),并生成类型化程序类,每个内核有一个类型化的 Java 方法(在编译时强制执行参数列表的正确性)
ScalaCL也使用JavaCL(通用的OpenCL支持的集合+Scala编译器插件来优化代码),这是一种避免编写任何内核的好方法(尽管在撰写本文时仍处于繁重的开发阶段)。
另一件需要考虑的事情是标准平台(至少是Windows,Linux和MacOS X)的二进制文件很容易获得,并且集成以构建Maven等系统。恕我直言,JavaCL曾经是最好的,但事情可能已经改变了(而且肯定会改变)。
最后,Marco Hutter的JOCL是另一个OpenCL绑定,但没有高级API。不过,对于低级调用,它可能被证明比OpenCL4Java(JavaCL)或JOCL更快。
编辑:JavaCL现在被Matthew Scarpino的OpenCL in Action书中的一章所涵盖。