JNI与JNA的性能

Question

我们有一个本地的c/asm应用程序，它使用GPU(OpenCL)来处理具有特定方法的大型encrypt/decrypt数据，它的工作原理非常完美，没有问题。项目的一部分(web和发行版)是由JEE开发的，我们只需要调用本机应用程序/库。

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

问题：

1. 为了更好(更快)的读/写解决方案，可以在JNI和JNA中通过直接(非托管)内存Java(ByteBuffer#allocateDirect())交换数据吗？
2. 是否可以通过本机代码管理和处理进程，并通过OpenCL代码( Java )访问GPU(共享)内存？
3. 表演呢？JNA比JNI快吗？

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

Answer 1

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

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

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

例如，如果你把99%的时间花在GPU和Java上，那么总花费的时间是99+2%的两倍，或者是慢1%。

Answer 2

来自南航官方常见问题解答

与自定义JNI相比，JNA的性能如何？ JNA直接映射可以提供接近自定义JNI的性能。几乎所有接口映射的类型映射功能都是可用的，尽管自动类型转换可能会带来一些开销。 使用JNA接口映射的单个本机调用的调用开销可能比等效的自定义JNI时间大一个数量级(~10X) (在应用程序的上下文中是否实际这样做是另一个问题)。从原始的角度来看，呼叫开销是几百微秒，而不是几十微秒。请注意，这是呼叫开销，而不是总呼叫时间。这种大小是使用动态维护的类型信息的系统与静态编译类型信息的系统之间的差异的典型。JNI方法调用中的硬代码类型信息，其中JNA接口映射在运行时动态地确定类型信息。 您可能会期望向JNA直接映射移动大约一个数量级的加速比，以及从那里移动到自定义JNI的两到三个因子。实际的差异将根据使用和函数签名而有所不同。与任何优化过程一样，您应该首先确定需要提高速度的地方，然后通过执行有针对性的优化来查看有多大的差异。在使用自定义JNI时，用Java编写所有东西的容易程度通常超过了小的性能收益。

Answer 3

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