Kann man Java auf Maschinencode compilieren?

http://de.wikipedia.org/wiki/Java_(Pro…Native_Compiler

Die Startup Time wird schon besser, aber die übliche Hotspot JVM von Sun bietet deutlich höhere Performance als das GCJ-Kompilat. Oftmals durchaus schneller als C/C++.

Zitat von Old Thrashbarg

Ich habe leider nie die LVA Compilerbau (oder heißt sie Übersetzerbau) gemacht. Vielleicht lernt man das dort?

Nein, eher noch in der LVA "Abstrakte Maschinen". Wobei da auch mehr das JITten erwaehnt wird.

Zitat von Ringding

Die Startup Time wird schon besser, aber die übliche Hotspot JVM von Sun bietet deutlich höhere Performance als das GCJ-Kompilat.

Das mag auf diese konkreten Implementierungen zutreffen. Im Allgemeinen gibt es allerdings nicht viele Gruende, warum ein JIT besseren Code produzieren sollte als ein Ahead-of-time-Compiler (im Gegenteil).

Zitat

Oftmals durchaus schneller als C/C++.

Gibts da belastbare veroeffentlichte Messungen?

Zitat von Plantschkuh!

Im Allgemeinen gibt es allerdings nicht viele Gruende, warum ein JIT besseren Code produzieren sollte als ein Ahead-of-time-Compiler (im Gegenteil).

Natürlich gibt es die. Der JIT weiß, welche Codepfade wie oft durchlaufen werden und kann entsprechend optimieren (geht mit PGO für C/C++ auch, zumindest wenn das halbwegs konstant ist; ist es aber üblicherweise). Der JIT weiß, auf welcher CPU er läuft. Z.B. kann er auf einem Uniprocessor-System teure atomic instructions weglassen. Nachdem's kaum mehr Uniprocessor-System gibt, wird das zwar weniger relevant, aber maschinenspezifische Optimierung kann immer noch einiges bringen. Der JIT kann virtual function calls durch statische ersetzen (und inlinen), wenn keine Klassen geladen sind, die diese Methoden überschreiben können. Und es gibt sicher noch viele mehr. Aber vor allem das mit dem Inlining von virtuellen Funktionen ist in Java ein wesentlicher Performance-Faktor.

Zitat

Gibts da belastbare veroeffentlichte Messungen?

Naja, es gibt http://shootout.alioth.debian.org/. Den Ergebnissen traue ich allerdings nicht sonderlich - hab gerade selber einen Benchmark davon ausprobiert (binary_trees), und bei mir war die Java-Version ziemlich genau doppelt so schnell wie die GCC C-Implementation. Auf der Page ist angegeben, dass die Java-Version 1.7 mal so lang braucht.

Zitat von Ringding

Natürlich gibt es die. Der JIT weiß, welche Codepfade wie oft durchlaufen werden und kann entsprechend optimieren (geht mit PGO für C/C++ auch, zumindest wenn das halbwegs konstant ist; ist es aber üblicherweise). Der JIT weiß, auf welcher CPU er läuft. Z.B. kann er auf einem Uniprocessor-System teure atomic instructions weglassen. Nachdem's kaum mehr Uniprocessor-System gibt, wird das zwar weniger relevant, aber maschinenspezifische Optimierung kann immer noch einiges bringen. Der JIT kann virtual function calls durch statische ersetzen (und inlinen), wenn keine Klassen geladen sind, die diese Methoden überschreiben können. Und es gibt sicher noch viele mehr. Aber vor allem das mit dem Inlining von virtuellen Funktionen ist in Java ein wesentlicher Performance-Faktor.

ahead-of-time compiler haben nochdazu probleme mit dynamic class loading, was für JIT compiler klarerweise gar kein problem ist. ahead-of-time compiler für java haben sich vor allem im embedded bereich durchgesetzt, da lebt man halt mit der einschränkung.

nur so nebenbei: java ist viel schneller als die meisten denken, trotz JIT compilation. ob man dadurch zum java-fan wird, ist jedem selbst überlassen

Zitat von Ringding

Natürlich gibt es die. Der JIT weiß, welche Codepfade wie oft durchlaufen werden und kann entsprechend optimieren

Und da wird dynamisch immer wieder neu kompiliert?

Zitat

Der JIT weiß, auf welcher CPU er läuft. Z.B. kann er auf einem Uniprocessor-System teure atomic instructions weglassen. Nachdem's kaum mehr Uniprocessor-System gibt, wird das zwar weniger relevant, aber maschinenspezifische Optimierung kann immer noch einiges bringen.

Pffft. Als ob man Compilern nicht sagen koennte, fuer was fuer eine CPU man kompilieren will. Ich sag nicht, dass es notwendigerweise ueblich ist, aber man muss schon Aepfel mit Aepfeln vergleichen.

Zitat

Der JIT kann virtual function calls durch statische ersetzen (und inlinen), wenn keine Klassen geladen sind, die diese Methoden überschreiben können.

Mit Trampolines und branch prediction sollte man diesen Effekt praktisch gratis kriegen, glaub ich. Inlining ist super, aber insbesondere, weil es je nach Aufrufkontext tolle globale Optimierungen erlaubt. Ob sich ein JIT die aber leisten kann, stell ich in Frage. (Du magst da aktuelle Literatur kennen.)

Zitat

Naja, es gibt http://shootout.alioth.debian.org/. Den Ergebnissen traue ich allerdings nicht sonderlich - hab gerade selber einen Benchmark davon ausprobiert (binary_trees), und bei mir war die Java-Version ziemlich genau doppelt so schnell wie die GCC C-Implementation. Auf der Page ist angegeben, dass die Java-Version 1.7 mal so lang braucht.

Welche Java-Version genau? Und hast du eh mit vergleichbaren Optimierungsflags kompiliert? Faktor 4 kann da eventuell hinkommen.

Zitat von kroni

nur so nebenbei: java ist viel schneller als die meisten denken, trotz JIT compilation.

Eh. Grad auf heutigen Computern kann man sich sowieso sehr viel an Implementierungsoverhead leisten.

Zitat von Plantschkuh!

Mit Trampolines und branch prediction sollte man diesen Effekt praktisch gratis kriegen, glaub ich. Inlining ist super, aber insbesondere, weil es je nach Aufrufkontext tolle globale Optimierungen erlaubt. Ob sich ein JIT die aber leisten kann, stell ich in Frage. (Du magst da aktuelle Literatur kennen.)

Invokes sind niemals gratis, auch nicht annähernd, was aber an der Spezifikation von invoke und Konsorten liegt. Generelles Inlining wird bei JIT nicht wirklich etwas bringen, aber Getter/Setter -- die sind in Java ja nicht unbedingt selten -- werden dadurch ohne großen Aufwand um ein Vielfaches schneller.

Zitat von Plantschkuh!

Und da wird dynamisch immer wieder neu kompiliert?

So ist es.

Zitat

Pffft. Als ob man Compilern nicht sagen koennte, fuer was fuer eine CPU man kompilieren will. Ich sag nicht, dass es notwendigerweise ueblich ist, aber man muss schon Aepfel mit Aepfeln vergleichen.

Naja, aber man braucht dann für jede CPU ein eigenes Binary. Oder man hat diesen Dispatch-Trick wie der Intel-Compiler, der aber auch nicht gratis ist. Außerdem habe ich beim GCC bisher immer feststellen müssen, dass die Optimierung auf genau meine CPU die Sache langsamer gemacht hat :o.

Zitat

Mit Trampolines und branch prediction sollte man diesen Effekt praktisch gratis kriegen, glaub ich. Inlining ist super, aber insbesondere, weil es je nach Aufrufkontext tolle globale Optimierungen erlaubt. Ob sich ein JIT die aber leisten kann, stell ich in Frage. (Du magst da aktuelle Literatur kennen.)

Hotspot inlined sehr aggressiv; das macht einen Riesenunterschied. Genau, v.a. wegen der globalen Optimierungen.

Zitat

Welche Java-Version genau? Und hast du eh mit vergleichbaren Optimierungsflags kompiliert? Faktor 4 kann da eventuell hinkommen.

java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b19, mixed mode)

Ja, hab schon auf die Flags geschaut. Fairerweise muss ich sagen, dass bei diesem speziellen Benchmark wahrscheinlich hauptsächlich der Memory-Allokator gefordert ist, und der ist bei Hotspot nahezu unschlagbar. Aber wieso das bei denen so viel langsamer ist als bei mir, verstehe ich trotzdem nicht.

Zitat von jeuneS2

Invokes sind niemals gratis [...] Inlining

Du redest von Invokes, die so weit optimiert sind, daß sie keine Invokes mehr sind. Ich auch...

Zitat von Ringding

Naja, aber man braucht dann für jede CPU ein eigenes Binary.

Hast du beim JIT ja auch, nur schmeißt du es wieder weg Ich sag ja nicht, daß es unbedingt praktikabel ist, wenn man immer alles für jede konkrete Maschine kompiliert (obwohl... Free(?)BSD, Gentoo, ...). Aber technisch möglich ist es.

Zitat

Hotspot inlined sehr aggressiv; das macht einen Riesenunterschied. Genau, v.a. wegen der globalen Optimierungen.

Hmm, hmm. Gut.

Zitat

java version "1.6.0_05"

Hab eigentlich gemeint, auf welche der vier Java-Messungen dort auf der Website du dich beziehst

Zitat

Hab eigentlich gemeint, auf welche der vier Java-Messungen dort auf der Website du dich beziehst

Java 6 -server natürlich. Alles andere ist ja Mist

Zitat von wescht

http://de.wikipedia.org/wiki/Java_(Pro…Native_Compiler

die compiler kenn ich aber sie funktionieren nicht[werbetext, oder das kompilieren funktioniert nicht weil die 1.6 features nicht unterstützt werden]. ich hab eine java1.6 anwendung die ich gern kompiliert hätte. kennts ihr noch andere compiler?

Zitat von rul0r

die compiler kenn ich aber sie funktionieren nicht[werbetext, oder das kompilieren funktioniert nicht weil die 1.6 features nicht unterstützt werden]. ich hab eine java1.6 anwendung die ich gern kompiliert hätte. kennts ihr noch andere compiler?

Leider nein. GCJ z.b. benutzt die Java Implementierung aus dem GNU CLASSPATH Projekt, und das ist unvollstaendig. Da die SUN Implementierung ja jetzt freie Software ist, wird es wohl in Zukunft auf diesem Gebiet besser aussehen.

Darf ich fragen was Du in deinem Posting mit "werbetext" gemeint hast?

bei einem der compiler wird beim starten des zuvor kompilierten programms ein popup mit der meldung: "kompiliert mit xyz" eingeblendet.

ich habs jetzt so gelöst:
da ich auf dem rechner wo ich das java programm einsetzen will nix installieren darf hab ich einfach mein JRE genommen und mit meinem programm auf den rechner kopiert. dann kann man einfach die java.exe aufrufen und ganz normal verwenden.