JNI 与 JNA 性能对比

Question

我们有一个原生的c/asm 应用程序，它利用 GPU(OpenCL) 以特定的方法处理大量的encrypt/decrypt 数据，它运行完美，没问题。 JEE正在开发一部分项目（web和distribution），我们只需要调用native application/library即可。

我们尝试使用Process 类将其称为分离的外部进程。问题是我们无法控制应用程序（事件、处理程序、线程等......）。我们还尝试将 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

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

使用直接缓冲区的优点是最关键的操作不使用 JNI 或 JNA，因此速度更快。他们使用内在的 when 意味着他们变成了单一的机器代码指令。

如果 Java 代码比 C 代码慢得多，则很可能代码没有得到足够的优化。一般来说，GPU 应该会做所有的工作，所以如果 Java 有点慢，这应该没什么区别。

例如如果您将 99% 的时间花在 GPU 上，而 Java 花费两倍的时间，那么总速度会慢 99+2% 或 1%。

Answer 2

来自JNA's official FAQ：

JNA 性能与自定义 JNI 相比如何？

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

使用 JNA 接口映射的单个本机调用的调用开销可能比等效的自定义 JNI 多一个数量级 (~10X)（它是否在您的应用程序上下文中实际执行是另一个问题）。用原始术语来说，调用开销大​​约是数百微秒而不是数十微秒。请注意，这是调用开销，而不是总调用时间。这个量级是使用动态维护类型信息的系统和静态编译类型信息的系统之间的典型差异。 JNI在方法调用中硬编码类型信息，其中JNA接口映射在运行时动态确定类型信息。

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

Answer 3

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

Answer 4

繁重的数字运算是在 C/GPU 中完成的，你所有的 Java C 接口所做的只是将数据输入/输出。如果这是一个瓶颈，我会感到惊讶。

无论如何，编写最简单、最清晰的代码来完成这项工作。如果结果证明性能不够，测量瓶颈在哪里，并一一解决，直到性能正常。程序员的时间比计算机的时间宝贵得多，除非是非常特殊的情况。