JNA - JNI - pures Java - Vergleich

[pmias]

Hallo Forum,

ich war neulich einmal neugierig, wie groß der Geschwindigkeitsvorteil von JNA und JNI gegenüber purer Java-Implementierung ist. Immerhin ist dies einer der Argumente der nativen Implementierung in C, etc.

Als Test habe ich folgenden Algorithmus sowohl in einer Java-Methode, als auch als zwei externe native Libraries in C implementiert und rufe sie mit JNI bzw. JNA auf:

double iterate(int steps)
   {
   double v = 1;
		  
   int i;
   for (i=1; i<=steps; i++) v /= i;
		  
   return v;
   }

Der Rückgabewert sei hier erst einmal zweitrangig. Es ging mir primär darum, den PC erst einmal in der Schleife zu beschäftigen. Alle zwei C-Implementierungen ließen sich auf meinem Linux-System kompilieren und anstandslos aufrufen.

Um das Zeitverhalten zu testen, habe ich diese Methode mit steps=2100000000 aufgerufen und den Aufruf 20x in einer Schleife wiederholt (Stichwort: Java Runtime Optimierung).

Das Ergebnis hat mich doch überrascht. Als Durchschnittszeiten gerundet kamen bei meinem PC heraus:

- 14 s (Java pur)
- 19 s (JNI)
- 28 s (JNA)

Gut, ich weiß, daß JNA langsamer als JNI ist. Aber ich hätte ehrlich erwartet, daß beide Varianten immer noch schneller als pures Java wären, wenn es um Berechnungen geht.

Kann diese Relationen irgendwer bestätigen? Muß man vielleicht noch dem Compiler ein wenig gut zureden, indem man ihm weitere Parameter mitgibt? Oder ist eine simple for-Schleife mit Division nicht zu optimieren - wenn nicht, was dann?

 

[Marco13]

So ein "Benchmark" ist höchst fragwürdig. Bei so kleinen Dingen ist da mit nativen Anbindungen nicht viel rauszuholen. Allein der native Aufruf dauert einen Moment (bei kleinerem Input und mehr Aufrufen würde das noch deutlicher ins Gewicht fallen). Das systematisch zu vergleichen und alles in Relation zu stellen wäre aufwändiger....
Das Vorurteil, Java sei langsam, stammt aus... den 90ern des letzten Jahrhunderts. Vielleicht könnte man durch irgendwelche Compilerflags (auf nativer Seite) noch was rausholen, vielleicht auch durch irgendwelche Tricks und Kniffe an der JVM (es gibt einen haufen undokumentierter Parameter), aber der Aufwand ist es i.A. nicht wert. Wenn es um reines numbercrunching geht, kann man höchstens dann etwas schneller machen, wenn man datenparallele Aufgaben hat, die man auf die GPU auslagern kann.

 

[ice-breaker]

Das Problem bei solchen Microbenchmarks ist einfach, dass es wirklich absolut davon abhängt, was der JIT/C-Compiler daraus macht.
Java könnte sogar hingehen und könnte sagen, dass es die Ergebnisse von iterate bei einer gegebenen Steps-Zahl cached (ich weiß nicht ob es die Optimierung cached).
Der GCC könnte, wenn er intelligent genug wäre, aber auch gleiche deine ganze Schleife wegoptimieren:

double iterate(int steps) {
  return 1.0 / (steps * (steps + 1) / 2);
}

(funktioniert nur bei positiven Steps)

Probier es doch mal mit den Benchmarks aus dem "Computer Language Benchmarks Game". Diese machen etwas mehr Logik wodurch der JNI/JNA-Aufrufoverhead im Gesammtkontext nicht mehr so relevant sein sollte.


Btw.: hast du gcc den Code optimieren lassen (-O3) ?

 

[pmias]

Mir ist schon klar, daß man die Sekunden nicht so genau nehmen darf. Und daß der Aufruf der nativen Libs auch einiges kostet. Genau deshalb hab ich ja so eine Schleife in die Libs selbst verlagert, so daß der Aufruf kaum noch ins Gewicht fallen sollte.

Wenn ich den Aufruf mit nur 2.000.000 tätige, dann bin ich bei allen Methoden unter einer Sekunde. Das würde bedeuten, daß der reine Aufruf der nativen Libs noch relativ schnell erledigt ist. Daraus würde ich jetzt folgern, daß die restlichen Zeiten in der Schleife selbst anfallen. Das wiederum wird durch den direkten Aufruft der C-Funktion von einer C-Main-Funktion aus belegt (ca. 3 sek.).

Ich frage mich jetzt nur, was da so lange dauert. In so ziemlich jedem JNI/JNA-Tutorial wird behauptet, daß Berechnungen schneller wären, würde man sie auslagern. Und, ja ich weiß, daß Java schneller ist, als sein Ruf. Genau deshalb habe ich diesen Praxistest ja gemacht. Ab wann macht es wirklich Sinn, eine komplexe Berechnung auszulagern oder doch lieber in Java zu implementieren, geht es um Geschwindigkeit?

 

[pmias]

@ice-breaker

Danke für die Anregungen, werde es demnächst testen. Nein, ich habe noch keine Optimierungen vorgenommen, ich wollte am Anfang alles möglichst ohne Spezialeinstellungen testen. Wie im obigen Post schon erwähnt, möchte ich rausfinden, ab wann eine Auslagerung komplexer Berechnungen wirklich Sinn macht.

 

[ice-breaker]

Wenigstens der GCC-Compiler sollte aber sein Compilerflag bekommen, sonst ist dein Benchmark nämlich vom Konzept unfair 😉
Der JIT-Compiler von Java optimiert automatisch und dein C-Code läuft unoptimiert einfach nur 1:1 in Maschinencode übersetzt 😉

Mach doch nochmal schnell das Optimierungsflag rein und teste es nochmal fix mit -O3, es würde mich echt interessieren, wie groß der Unterschied dann noch ist.

An Introduction to GCC - Optimization levels

 

[Ark]

Wenigstens der GCC-Compiler sollte aber sein Compilerflag bekommen, sonst ist dein Benchmark nämlich vom Konzept unfair 😉
Der JIT-Compiler von Java optimiert automatisch und dein C-Code läuft unoptimiert einfach nur 1:1 in Maschinencode übersetzt 😉

Und es kommt noch schlimmer: Im Gegensatz zu einem dynamisch optimierenden Compiler kann der GCC nur statisch optimieren. Soll heißen: der HotSpot-Compiler kann ein Stück Code mal so, mal anders optimieren, weil er zur Laufzeit Informationen vorliegen hat, die ihm garantieren, dass die jeweilige Optimierung möglich ist, ohne die Semantik zu ändern.

Dagegen kann es gut sein, dass der GCC weder die eine noch die andere Optimierung vornehmen kann, weil er nicht garantieren kann, dass die Semantik dabei unverändert erhalten bleibt.

Ark