进行 JNI 调用的定量开销是多少?

2022-08-31 14:37:16

仅基于性能,大约有多少“简单”的java行与进行JNI调用的性能相同?

或者尝试以更具体的方式表达问题,如果一个简单的java操作,例如

someIntVar1 = someIntVar2 + someIntVar3;

被赋予一个“CPU工作”索引,那么进行JNI调用的开销的典型(大致)“CPU工作”索引是什么?1


此问题忽略了等待本机代码执行所花费的时间。在电话术语中,它严格地是关于呼叫的“标志下降”部分,而不是“呼叫速率”。


提出这个问题的原因是要有一个“经验法则”,知道当您知道给定操作的本机成本(来自直接测试)和java成本时,何时尝试编写JNI调用。它可以帮助您快速避免对 JNI 调用进行编码的麻烦,结果却发现标注开销消耗了使用本机代码的任何好处。

编辑:

有些人对CPU,RAM等的变化感到困扰。这些实际上都与问题无关 - 我要求Java代码行的相对成本。如果CPU和RAM很差,那么它们对于java和JNI来说都是差的,所以环境方面的考虑应该平衡。JVM版本也属于“不相关”类别。

这个问题不是要求以纳秒为单位的绝对时间,而是以“简单Java代码行”为单位的“工作努力”。


答案 1

快速分析器测试结果:

Java 类:

public class Main {
    private static native int zero();

    private static int testNative() {
        return Main.zero();
    }

    private static int test() {
        return 0;
    }

    public static void main(String[] args) {
        testNative();
        test();
    }

    static {
         System.loadLibrary("foo");
    }
}

C 库:

#include <jni.h>
#include "Main.h"

JNIEXPORT int JNICALL 
Java_Main_zero(JNIEnv *env, jobject obj)
{
    return 0;
}

结果:

single invocation10 calls in a loop100 calls in a loop

系统详细信息:

java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-1)
OpenJDK Server VM (build 23.2-b09, mixed mode)
Linux visor 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 GNU/Linux

更新:x86(32/64 位)和 ARMv6 的卡尺微基准测试如下所示:

Java 类:

public class Main extends SimpleBenchmark {
    private static native int zero();
    private Random random;
    private int[] primes;

    public int timeJniCall(int reps) {
        int r = 0;
        for (int i = 0; i < reps; i++) r += Main.zero();
        return r;
    }

    public int timeAddIntOperation(int reps) {
        int p = primes[random.nextInt(1) + 54];   // >= 257
        for (int i = 0; i < reps; i++) p += i;
        return p;
    }

    public long timeAddLongOperation(int reps) {
        long p = primes[random.nextInt(3) + 54];  // >= 257
        long inc = primes[random.nextInt(3) + 4]; // >= 11
        for (int i = 0; i < reps; i++) p += inc;
        return p;
    }

    @Override
    protected void setUp() throws Exception {
        random = new Random();
        primes = getPrimes(1000);
    }

    public static void main(String[] args) {
        Runner.main(Main.class, args);        
    }

    public static int[] getPrimes(int limit) {
        // returns array of primes under $limit, off-topic here
    }

    static {
        System.loadLibrary("foo");
    }
}

结果 (x86/i7500/Hotspot/Linux):

Scenario{benchmark=JniCall} 11.34 ns; σ=0.02 ns @ 3 trials
Scenario{benchmark=AddIntOperation} 0.47 ns; σ=0.02 ns @ 10 trials
Scenario{benchmark=AddLongOperation} 0.92 ns; σ=0.02 ns @ 10 trials

       benchmark     ns linear runtime
         JniCall 11.335 ==============================
 AddIntOperation  0.466 =
AddLongOperation  0.921 ==

结果(amd64/phenom 960T/Hostspot/Linux):

Scenario{benchmark=JniCall} 6.66 ns; σ=0.22 ns @ 10 trials
Scenario{benchmark=AddIntOperation} 0.29 ns; σ=0.00 ns @ 3 trials
Scenario{benchmark=AddLongOperation} 0.26 ns; σ=0.00 ns @ 3 trials

   benchmark    ns linear runtime
         JniCall 6.657 ==============================
 AddIntOperation 0.291 =
AddLongOperation 0.259 =

结果 (armv6/BCM2708/Zero/Linux):

Scenario{benchmark=JniCall} 678.59 ns; σ=1.44 ns @ 3 trials
Scenario{benchmark=AddIntOperation} 183.46 ns; σ=0.54 ns @ 3 trials
Scenario{benchmark=AddLongOperation} 199.36 ns; σ=0.65 ns @ 3 trials

   benchmark  ns linear runtime
         JniCall 679 ==============================
 AddIntOperation 183 ========
AddLongOperation 199 ========

总而言之,JNI调用似乎大致相当于典型(x86)硬件和热点VM上的10-25个java操作。毫不奇怪,在优化程度较低的零虚拟机下,结果却大不相同(3-4 次操作)。


感谢@Giovanni Azua和@Marko Topolnik的参与和提示。


答案 2

因此,我刚刚使用Eclipse Mars IDE,JDK 1.8.0_74和VirtualVM profiler 1.3.8以及Profile Startup插件测试了Windows 8.1,64位JNI调用C的“延迟”。

设置:(两种方法)
SOMETHING()传递参数,执行操作,并返回
参数NOTHING()在相同的参数中传递,对它们不执行任何操作,并返回相同的参数。

(每个被调用270次)
SOMETHING() 的总运行时间: 6523ms
NOTHING() 的总运行时间: 0.102ms

因此,在我的情况下,JNI调用可以忽略不计。


推荐