一尘不染

JNI与JNA的性能

java

我们有一个本机c/asm应用程序,它使用GPU(OpenCL)encrypt/decrypt通过一种特定的方法处理大数据,并且运行得很好,没有问题。该项目的一部分(网络和分发)由进行开发JEE,我们只需要调用本机应用程序/库即可。

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

问题:

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

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


阅读 608

收藏
2020-12-03

共1个答案

一尘不染

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

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

如果Java代码比C慢得多,则可能是代码未充分优化。通常,GPU应该完成所有工作,因此,如果Java速度稍慢,则不会有太大的不同。

例如,如果您将99%的时间花费在GPU上,而Java花费的时间是原来的两倍,则总时间将降低99 + 2%或1%。

2020-12-03