Wie hoch ist der quantitative Overhead bei einem JNI-Aufruf?

Wie viele “einfache” Java-Zeilen allein auf der Grundlage der Leistung sind ungefähr die äquivalenten Leistungseinbußen bei einem JNI-Aufruf?

Oder um die Frage konkreter auszudrücken, ob eine einfache Java-Operation wie z

someIntVar1 = someIntVar2 + someIntVar3;

erhielt einen “CPU work”-Index von 1was wäre der typische (normale) “CPU-Arbeits”-Index für den Overhead beim Tätigen des JNI-Aufrufs?

Diese Frage ignoriert die Wartezeit auf die Ausführung des nativen Codes. Im Telefonjargon geht es ausschließlich um den “Flag-Fall”-Teil des Anrufs, nicht um die “Anrufrate”.

Der Grund für diese Frage ist, eine “Faustregel” zu haben, um zu wissen, wann man sich die Mühe machen sollte, einen JNI-Aufruf zu codieren, wenn man die nativen Kosten (aus direkten Tests) und die Java-Kosten einer bestimmten Operation kennt. Es könnte Ihnen helfen, schnell den Aufwand zu vermeiden, den JNI-Aufruf zu codieren, nur um festzustellen, dass der Callout-Overhead alle Vorteile der Verwendung von nativem Code aufzehrt.

Bearbeiten:

Einige Leute hängen sich an Variationen in CPU, RAM usw. auf. Diese sind für die Frage praktisch irrelevant – ich frage nach dem relativ Kosten für Zeilen Java-Code. Wenn CPU und RAM schlecht sind, sind sie sowohl für Java als auch für JNI schlecht, sodass sich Umweltaspekte ausgleichen sollten. Die JVM-Version fällt ebenfalls in die Kategorie “irrelevant”.

Diese Frage fragt nicht nach einem absoluten Timing in Nanosekunden, sondern nach einem “Arbeitsaufwand” in Einheiten von “Zeilen einfachen Java-Codes”.

Quick-Profiler-Testergebnisse:

Java-Klasse:

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-Bibliothek:

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

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

Ergebnisse:

Systemdetails:

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

Aktualisieren: Caliper Mikro-Benchmarks für x86 (32/64 Bit) und ARMv6 sind wie folgt:

Java-Klasse:

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");
    }
}

Ergebnisse (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 ==

Ergebnisse (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 =

Ergebnisse (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 ========

Um die Dinge ein wenig zusammenzufassen, es scheint so JNI Aufruf entspricht ungefähr 10-25 Java-Operationen bei einem typischen (x86) Hardware und Hotspot-VM. Kein Wunder, unter viel weniger optimiert Null-VMdie Ergebnisse sind ziemlich unterschiedlich (3-4 ops).

Danke an @Giovanni Azua und @Marko Topolnik für die Teilnahme und Hinweise.

Also habe ich gerade die „Latenz“ für einen JNI-Aufruf an C unter Windows 8.1, 64-Bit, mit der Eclipse Mars IDE, JDK 1.8.0_74 und VirtualVM Profiler 1.3.8 mit dem Profile Startup Add-on getestet.

Setup: (zwei Methoden)
SOMETHING() übergibt Argumente, erledigt Sachen und gibt Argumente zurück
NOTHING() übergibt dieselben Argumente, macht nichts mit ihnen und gibt dieselben Argumente zurück.

(jeder wird 270 mal angerufen)
Gesamtlaufzeit für ETWAS(): 6523ms

Gesamtlaufzeit für NICHTS(): 0,102 ms

Daher sind in meinem Fall die JNI-Aufrufe ziemlich vernachlässigbar.

Sie sollten eigentlich selbst testen, was die “Latenz” ist. Die Latenz wird in der Technik als die Zeit definiert, die zum Senden einer Nachricht der Länge Null benötigt wird. In diesem Zusammenhang würde es dem Schreiben des kleinsten Java-Programms entsprechen, das a aufruft do_nothing leere C++-Funktion und berechnen Sie Mittelwert und stddev der verstrichenen Zeit über 30 Messungen (machen Sie ein paar zusätzliche Aufwärmaufrufe). Sie werden vielleicht von den unterschiedlichen Durchschnittsergebnissen überrascht sein, die für verschiedene JDK-Versionen und Plattformen dasselbe tun.

Nur so erhalten Sie die endgültige Antwort, ob die Verwendung von JNI für Ihre Zielumgebung sinnvoll ist.