JavaCL 和 JogAmp JOCL 相比如何？
JavaCL 使用 JNA，JOCL 使用 JNI，因此我希望 JavaCL 能够表现出更好的跨平台兼容性，而 JOCL 通常应该具有更好的性能。 JOCL 与 JOGL2 一起进行测试，这将使在 CL 中使用 GL 对象变得容易，反之亦然。 JavaCL 能够从当前 GL 上下文生成其上下文。 JavaCL 受 GPL 保护，JOCL 在 BSD 许可证下分发。
对于这两种方法还有什么可说的呢？ 有没有什么好的比较？
JavaCL uses JNA, JOCL uses JNI instead, so I expect JavaCL to show better cross-platform compatibility, while JOCL should generally turn out to have better performance. JOCL gets tested alongside JOGL2, which should make it easy to use GL objects in CL and vice versa. JavaCL is able to generate its context from the current GL context.
JavaCL is protected by the GPL, JOCL is distributed under the BSD license.
What else can be said about these two approaches?
Are there any good comparisons out there?
JavaCL: http://code.google.com/p/javacl/
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
（免责声明：我是 JavaCL 和 BridJ 的作者）
除了基于 JNA 的版本之外，JavaCL 还有一个功能齐全的 BridJ 端口，该端口完全在 BSD 下授权（因为 BridJ 本身就是 BSD 授权的）。
仅供参考，BridJ 的每次调用开销明显低于 JNA，接近 JNI 性能，同时仍然非常便携（目前已发布适用于 Windows、Linux 和 MacOS X 的 32 位和 64 位二进制文件，但其他平台也在计划中）。
不过，低级绑定的性能并不是唯一需要考虑的事情。虽然 JavaCL 和 JOCL 的面向对象 API 看起来很相似，但您必须注意额外的好处。我不知道 JOCL，但 JavaCL 附带：
JavaCL 也被 ScalaCL（通用 OpenCL 支持的集合 + 用于优化代码的 Scala 编译器插件），这是避免编写任何内核的好方法（尽管在撰写本文时仍在大力开发中）。
另一件需要考虑的事情是标准平台（至少是 Windows、Linux 和 MacOS X）的二进制文件的轻松可用性以及构建 Maven 等系统的集成。恕我直言，JavaCL 曾经是最好的，但情况可能已经改变（并且肯定会改变）。
最后，Marco Hutter 的 JOCL 是另一个 OpenCL 绑定，但没有高级 API。不过，对于低级调用，它可能比 OpenCL4Java (JavaCL) 或 JOCL 更快。
编辑：JavaCL 现在包含在 Matthew Scarpino 的 OpenCL in Action 书中的一章中。
(Disclaimer: I'm the author of JavaCL and BridJ)
In addition to its JNA-based version, JavaCL has a fully-functional BridJ port that's entirely licensed under BSD (as BridJ is itself BSD-licensed).
FYI BridJ offers significantly lower per-call overhead than JNA, nearing JNI performance while still being very portable (it's currently released with 32 and 64 bits binaries for Windows, Linux and MacOS X, but other platforms are planned).
The performance of low-level bindings is not the only thing to consider, though. While the object-oriented APIs of JavaCL and JOCL look similar, you have to look after the extra goodies. I don't know about JOCL, but JavaCL ships with :
JavaCL is also used by ScalaCL (general-purpose OpenCL-backed collections + Scala compiler plugin to optimize code), which is a nice way of avoiding to write any kernel at all (albeit still in heavy development as of this writing).
Another thing to consider is the easy availability of binaries for standard platforms (Windows, Linux and MacOS X at least) and integration to build systems such as Maven. JavaCL used to be the best IMHO, but things might have changed (and for sure will change).
Finally, Marco Hutter's JOCL is another OpenCL binding, but with no high-level API. It might prove to be faster than OpenCL4Java (JavaCL) or JOCL for low-level calls, though.
EDIT: JavaCL is now covered by a chapter in Matthew Scarpino's OpenCL in Action book.
Raquel Medina Dominguez 为其“Ingeniería en Informática”学位撰写了一篇论文，题为“评估 OpenCL 的不同 Java 绑定”。本文对 JogAmp JOCL、JOCL 和 JavaCL 进行了比较。它对树项目的性能、易用性和内存消耗进行评分。
本文包含的设置说明将帮助您开始使用三种 Java OpenCL 绑定实现中的任何一种。
http://e-archivo.uc3m.es/handle/10016/17183 ?locale=en - 评估 OpenCL 的不同 Java 绑定
PDF： http://e-archivo.uc3m.es/bitstream /10016/17183/5/finalversionPFC_Raquel_Medina.pdf
结论见第 40 页。
Raquel Medina Dominguez have written a paper for his "Ingeniería en Informática" degree titled "Evaluating different Java bindings for OpenCL". This paper compares JogAmp JOCL, JOCL and JavaCL. It scores the tree projects on performance, easy to use and memory consumption.
The paper include set-up instructions that will help you getting started using any of the three Java OpenCL binding implementations.
http://e-archivo.uc3m.es/handle/10016/17183?locale=en - Evaluating different Java bindings for OpenCL
PDF: http://e-archivo.uc3m.es/bitstream/10016/17183/5/finalversionPFC_Raquel_Medina.pdf
Conclusions on page 40.
JOCL 的设计与 JOGL 或 JOAL 非常相似，并且（像所有 http://jogamp.org 项目一样）直接生成来自构建时的 OpenCL 规范头文件。这就是为什么我们以两个级别公开 API：1:1 规范符合低级绑定和手写的不太冗长的高级绑定。基于 JNI 的绑定是静态的，并且针对最小的运行时开销进行了优化。我们为所有常见的 os-arch 组合提供（经过测试的）构建，很快还将为一些移动设备提供构建。
Marco Hutter 的 JOCL.org 也是基于 JNI 的，但完全是手写的并且级别相当低（如前所述）。
最好的问候，
-michael（JOCL 领导，JOGL 维护者）
JOCL is in its design very similar to JOGL or JOAL and is (like all http://jogamp.org projects) directly generated from the OpenCL specification header files at build time. This is why we expose the API in two levels: the 1:1 spec conform low level binding and a hand written much less verbose high level binding. The JNI based binding is static and is optimised for minimal runtime overhead. We provide (tested) builds for all common os-arch combinations and soon also for a few mobile devices.
Marco Hutter's JOCL.org is also JNI based but entirely hand written and fairly low level (as already mentioned before).
best regards,
-michael (JOCL lead, JOGL maintainer)