问JavaCL和JogAmp JOCL有什么不同？

EN

JOCL在设计上与JOGL或JOAL非常相似，并且(像所有http://jogamp.org项目一样)在构建时直接从OpenCL规范头文件生成。这就是为什么我们在两个级别公开API :符合1:1规范的低级绑定和手写的少得多冗长的高级绑定。基于JNI的绑定是静态的，并针对最小的运行时开销进行了优化。我们为所有常见的os-arch组合提供(经过测试的)构建，很快还会为一些移动设备提供构建。

Marco Hutter的JOCL.org也是基于JNI的，但完全是手写的，而且级别相当低(前面已经提到过)。

诚挚的问候,

-michael (JOCL主管、JOGL维护者)

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

除了它的基于JNA的版本之外，JavaCL还有一个全功能的BridJ端口，它完全是在BSD下授权的(因为BridJ本身也是BSD授权的)。

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

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

• transparent #include of file from the Java classpath or any URL
• a random number generator (库，而不是演示!)
• a nice GUI to experiment with image transform kernels within seconds < OpenCL >h214
• 一个maven插件，解析主内核(可在src/opencl/opencl中找到)并生成类型化的程序类，每个内核使用一个类型化的Java方法生成类型化的程序类(在compile-time)

强制执行参数列表的正确性

ScalaCL也使用了JavaCL (通用的OpenCL支持的集合+ Scala编译器插件来优化代码)，这是一种很好的方式来避免编写任何内核(尽管在撰写本文时仍在进行繁重的开发)。

另一件要考虑的事情是，标准平台(至少是Windows、Linux和Maven )的二进制文件很容易获得，并且可以集成来构建像MacOS这样的系统。JavaCL曾经是最好的IMHO，但情况可能已经改变(肯定会改变)。

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

编辑: Matthew Scarpino的OpenCL in Action一书中有一章介绍了JavaCL。

Raquel Medina Dominguez为他的"Ingeniería en Informática“学位写了一篇论文，题目是”为OpenCL评估不同的Java绑定“。本文对JogAmp、JOCL和JavaCL进行了比较。它根据性能、易用性和内存消耗对树项目进行评分。本文包含的设置说明将帮助您开始使用三种Java实现中的任何一种。

http://e-archivo.uc3m.es/handle/10016/17183?locale=en -评估OpenCL的不同Java绑定:第40页的http://e-archivo.uc3m.es/bitstream/10016/17183/5/finalversionPFC_Raquel_Medina.pdf结论。