java - JavaCL 和 JogAmp JOCL 比较如何？

Question

JavaCL 使用 JNA，JOCL 使用 JNI，所以我希望 JavaCL 表现出更好的跨平台兼容性，而 JOCL 通常应该具有更好的性能。 JOCL 与 JOGL2 一起进行了测试，这应该使得在 CL 中使用 GL 对象变得容易，反之亦然。 JavaCL 能够从当前的 GL 上下文中生成它的上下文。JavaCL 受 GPL 保护，JOCL 在 BSD 许可下分发。

关于这两种方法还有什么可以说的？有什么好的比较吗？

JavaCL:http://code.google.com/p/javacl/

JOCL:http://jogamp.org/jocl/www/

Answer 1

(免责声明:我是 JavaCL 和 BridJ 的作者)

除了其基于 JNA 的版本之外，JavaCL 还具有一个功能齐全的 BridJ 端口，该端口完全在 BSD 下获得许可(因为 BridJ 本身已获得 BSD 许可)。

仅供引用 BridJ提供比 JNA 低得多的每次调用开销，接近 JNI 性能，同时仍然非常便携(它目前发布了用于 Windows、Linux 和 MacOS X 的 32 位和 64 位二进制文​​件，但其他平台也在计划中)。

不过，低级绑定(bind)的性能并不是唯一要考虑的事情。虽然 JavaCL 和 JOCL 的面向对象 API 看起来很相似，但您必须注意额外的好处。我不知道 JOCL，但 JavaCL 附带:

• 透明#include 来自 Java 类路径或任何 URL 的文件
• 程序二进制文件的自动和透明缓存
• 还原效用
• 线性代数实用程序
• 一个随机数生成器(一个库，而不是一个演示!)
• 一个nice GUI to experiment with image transform kernels within seconds
• 一个 Maven 插件，用于解析 OpenCL 内核(位于 src/main/opencl 中)并为每个内核生成带有一个类型化 Java 方法的类型化程序类(在编译时强制参数列表的正确性)

ScalaCL 也使用 JavaCL (通用 OpenCL 支持的集合 + Scala 编译器插件来优化代码)，这是避免编写任何内核的好方法(尽管在撰写本文时仍处于大量开发阶段)。

另一件需要考虑的事情是标准平台(至少是 Windows、Linux 和 MacOS X)的二进制文件的易用性以及与 Maven 等构建系统的集成。 JavaCL 曾经是最好的恕我直言，但情况可能已经改变(而且肯定会改变)。

最后，Marco Hutter's JOCL是另一个 OpenCL 绑定(bind)，但没有高级 API。不过，对于低级调用，它可能比 OpenCL4Java (JavaCL) 或 JOCL 更快。

编辑:JavaCL 现在包含在 Matthew Scarpino 的一章中 OpenCL in Action书。