JNI 与 JNA 性能

Question

我们有一个本机< code>c/asm应用程序，它利用GPU(OpenCL)通过特定的方法对大量< code >数据进行加密/解密,它运行得非常完美，没有任何问题。该项目的一部分(网络和分发)正在由< code>JEE开发，我们只需要调用原生应用程序/库。

我们已经尝试使用进程类将其称为分离的外部进程。问题是我们无法控制应用程序（事件、处理程序、线程等…）。我们还尝试将C代码切换为Java代码，但性能下降了。除了将本机代码作为进程运行之外，我还在考虑JNA和JNI，但有一些问题。

问题：

1. 为了获得更好（更快）的读/写解决方案，是否可以通过JNI和JNA中的直接（非托管）内存[Java（ByteBuffer#allocateDirect（））]交换数据
2. 是否可以通过本地代码管理和处理进程，并通过Java代码（OpenCL-lib）访问GPU（共享）内存
3. 性能如何？JNA比JNI快吗

我们在Redhat Linux6 x64上有两个AMD W7000集群设备。

Answer 1

我开发了一个简单的dll，并放置了一个空函数，它什么都不做。然后我用JNA和JNI从dll调用了该函数，所以我尝试计算调用它们的成本。在多次调用后查看性能时，JNI比JNA快30-40倍。

Answer 2

来自JNA的官方常见问题:

JNA直接映射可以提供接近自定义JNI的性能。接口映射的几乎所有类型映射特性都是可用的，尽管自动类型转换可能会产生一些开销。

使用JNA接口映射的单个本机调用的调用开销可能比等效的定制JNI大一个数量级（约10倍）（在应用程序的上下文中是否确实如此是另一个问题）。粗略地说，调用开销大约为数百微秒，而不是几十微秒。请注意，这是呼叫开销，而不是总呼叫时间。这种大小是使用动态维护的类型信息的系统与静态编译类型信息的的系统之间的典型差异。JNI硬编码方法调用中的类型信息，其中JNA接口映射在运行时动态确定类型信息。

您可能会期望转移到JNA直接映射大约一个数量级的加速，以及从那里转移到自定义JNI的2到3倍的加速。实际差异将根据使用情况和函数签名而有所不同。与任何优化过程一样，您应该首先确定需要提高速度的地方，然后通过执行有针对性的优化来查看差异有多大。使用自定义JNI时，在Java中编程的便利性通常超过了小的性能提升。

Answer 3

JNA比JNI慢得多，但要容易得多。如果性能不是问题，请使用JNA。

使用直接缓冲区的优点是，最关键的操作不使用 JNI 或 JNA，因此速度更快。当它们变成单个机器代码指令时，它们使用内在的。

如果Java代码明显比C慢，则可能是代码没有得到足够的优化。一般来说，GPU应该完成所有的工作，所以如果Java慢一点，这应该不会有太大区别。

例如，如果你花99%的时间在GPU上，而Java花两倍的时间，总的来说会慢99 2%或1%。