GCJ bzw. native Java-Programme

[Fret]

Hallo zusammen,

ich weiß, dass das Thema schon mehrmals diskutiert wurde, aber ich bin aus den bestehenden Threads nicht so recht schlau geworden. Folgendes Problem habe ich: Ich habe ein Programm, dass numerische Operationen durchführt und wirklich schnell sein soll. Ich habe die Geschwindigkeits des Codes bereits optimieren können, frage mich nun aber, ob nicht ein natives Compilat schneller wäre. GCJ kann sowas ja offensichtlich, oder? Ich habe in diesem Zusammenhang mal das Stichwort "V8" gehört, was hat es damit auf sich? Gibt es noch andere Compiler, die nativen Maschinencode für eine bestimmte Platform erzeugen können?

Vielen Dank schonmal,
Arne

 

[foobar]

V8 ist die Javascript-Engine von Google oder gibts noch ein gleichnamiges Projekt?

 

[Fret]

Jupp, habe es nun auch gerade gefunden. Der Punkt wäre also geklärt. Bleibt noch der Rest.

 

[Wildcard]

Wenn du keine uralt JRE verwendest, dann hat sie einen JIT Compiler und übersetzt die Hot-Spots automatisch in ein natives, optimiertes Kompilat.

 

[FArt]

Auch andere Compiler von Hochsprachen erzeugen lediglich bestimmten Code, der für deine Problematik nicht unbedingt optimal ist. Die Einflußmöglichkeiten, durch Gestaltung des Sourcecodes das Kompilat zu "optimieren" gibt es nicht mehr in dem Ausmaß, wie früher.

Noch ein Hinweis zu Java: die JIT Compile und Hotspot-Engines sind mittlerweile so optimiert, dass vorwiegend nativer Code ausgeführt wird. Im Verhältnis zur Gesamtlaufzeit ist die Compilezeit (Bytecode->nativ) in der Regel zu vernachlässigen.

Ein Beispiel aus der Praxis: Matrixtransformationen, FFT u.Ä. (mehrdimensional, größer 1000 in einer Dimension) waren für Berechnungen (finite Elemente) in Java (SUN 1.4) kaum langsamer als optimierter C Code (ausgeführt auf Solaris).

 

[tfa]

Ist zwar nicht direkt Numerik (und ein Vergleich zwischen einer "echten" kompilierten Sprache und Java):

http://www.springerlink.com/content/x44m11432wg53553/

Besides the choice of an automated software method for selecting maximally diverse compounds from a large pool of molecules, it is the implementation of the algorithm that critically determines the usefulness of the approach. The speed of execution of two implementations of the Maxmin algorithm is compared for the selection of maximally diverse subsets of large compound collections. Different versions of the software are compared using various C compiler options and Java virtual machines. The analysis shows that the Maxmin algorithm can be implemented in both languages yielding sufficient speed of execution. For large compound libraries the Java version outperformes the C version. While the Java version selects the same compounds independent of the virtual machine used, the C version produces slightly different subsets depending on the compiler and on the optimization settings.

Das war 2004. Zwischenzeitlich sollte JIT nicht langsamer geworden sein.

Wer glaubt, durch AOT-Compiler für Java könnten nennenswerte Geschwindigkeitsvorteile erzielt werden, ist meistens auf dem Holzweg.

 

[Fret]

Ok, das klingt relativ eindeutig. Vielen Dank für die hilfreichen Antworten, ich werde selber auch nochmal nach entsprechenden Berichten suchen, möglichst mit Referenz zu numerischen Verfahren.

 

[Fret]

Nachtrag: Ich benutze JRE 1.6 (mit Eclipse 3.3.2). Da sollte dann doch wohl vernünftige HotSpot-Optimierung zu erwarten sein...