Java in nativcode

[edze]

Hi,
ich würde gerne wissen ob man Java wie C in nativcode umwandeln kann und ob Java dann an die Performens von C rankommt.

Danke im Vorraus

Eduard Zehrt

 

[Guest]

Ich meinte Maschinencode!

 

[nekton]

jein - es geht basiziell schon, wenn man den entsprechenden kompiler hat. ich habe da was von einem arbeitskollegen gehoert, das der GNU java compiler sowas wohl unterstuetzt, es aber ein rechtliches problem gab, da die vorkompilierten klassen dazu wohl neu kompiliert werden muessten. so ganz habe ich das allerdings leider nicht mehr im kopf.

es gibt wohl auch ein betriebsystem, das java code native ausfuehrt (und auch mal abgesehen von den java prozessoren).

 

[tomkruse]

Hi!

Aber irgendwie geht das doch am Sinn von Java vorbei, oder?

Cu - Tom.

 

[marsias]

Hi!

Ja man kann java code auch native-kompilieren.
Aber ist wohl nicht unbedingt schneller.

Der sinn von java ist ja eh plattform-unabhängigkeit.

Bei test haben wohl IBM JRE sehr gut abgeschnitten.
Viel schneller als die von sun und speicher-freundlicher.

wenn java als native-kompiliert funktionieren nur kommandozeilen programme.
swing usw. wird nicht unterstützt.

darüber hinaus werden die native-programme viel größer,
weil die notwendigen bibliotheken wohl einkompiliert werden müssen.

also im test war ibm top. würde auch damit arbeiten und selber vergleiche
anstellen.

mfg

 

[Guest]

wenn java als native-kompiliert funktionieren nur kommandozeilen programme.
swing usw. wird nicht unterstützt.

Das liegt ja aber wohl mehr daran, dass es keine vernünftigen Native-Compiler gibt?

 

[Slava]

ausschnit aus galileocomputing openbook http://www.galileocomputing.de/openbook/javainsel3/ Java ist auch ein Insel
Für die Konvertierung und Kompilierung von Bytecode in ein direkt ausführbares Format (Java to Native Code Compiler) ist die Firma Excelsior, LLC (http://www.excelsior-usa.com/jet.html) mit ihrem Tool JET bekannt geworden. Die Firma hat unter anderem Modula-2 und Oberon-2 Compiler entworfen und eine langjährige Erfahrung mit Optimierungstechniken. JET nimmt als Eingabe kompilierte Klassendateien und wandelt diese in ausführbare Exe-Dateien um. Neben der reinen Umsetzung wird der Code auch gleich optimiert. Zwischencode in C wird nicht erstellt, und daher ist es auch nicht notwendig, dass ein C–Compiler installiert ist.

Voraussetzung für die Kompilierung ist eine Menge freier Speicher und ein installiertes Java SDK in der Version 1.3 für JET 2.5. JET unterstützt alle Java 2 SE-Pakete inklusive AWT/Swing, JNI und Invocation-API. In der Professional Edition gibt es zusätzlich Unterstützung zum dynamischen Laden von Klassen, was etwa bei RMI benötigt wird. Eine freie Testversion, Excelsior JET 2.5 Evaluation Package, lässt sich unter http://www.excelsior-usa.com/jetdleval.html beziehen. Sie ist für 60 Tage zur Benutzung frei.

Andere interessante Compiler, die nativen Code erzeugen, sind:

Jove von Instantiations unter http://www.instantiations.com/ und
BulletTrain von Natural Bridge unter http://www.naturalbridge.com

 

[Murmeltier]

Dürfte auch nicht uninteressant sein

http://gcc.gnu.org/java/

GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile:
Java source code directly to native machine code,
Java source code to Java bytecode (class files),
and Java bytecode to native machine code.

zudem ist gcc freie Software.

 

[Guest]

An die Performancevon C kommt es nicht heran, wird aber um einiges
schneller. Schau Dir die Benchmarks von Excelsior-JET an, die sagen
mehr als 1000 Worte.

 

[Isaac]

Die Frage stellt sich doch garnicht.

Es ist doch nur eine Frage was ich nutze. Einen Interpreter, eine JIT Compilier oder einen HotSpot Compilier.

Ich klaue hier mal aus der sehr guten Zusammenstellung von Sebastian Ritter Make Java - Performance

Der Bytecode Interpreter arbeitet die einzelnen Befehle im
Javabytecode wie bei einer Scriptsprache ab. Der jeweilige Befehl wird
eingelesen in Maschinencode umgesetzt und ausgeführt. Da dies für
jeden Befehl auch bei nochmaligem Aufruf neu geschieht, hält sich die
Ausführungsgeschwindigkeit in Grenzen. Sie ermöglichen keine
Nutzung der Maschinenarchitektur, wie Cache und Sprungvorhersage.
Bytecode Interpreter sind jedoch die Mindestumsetzung einer JVM und
daher auf allen Javaplattformen vorhanden.

Just In Time [JIT] Compiler sind die Nachfolger der Bytecode
Interpreter. Sie übersetzen den gesamten Bytecode vor Ausführung in
Maschinencode. Wenn dies geschehen ist wird lediglich auf den
Maschinencode zurückgegriffen. Durch die Übersetzung des Bytecode
18
erreichen JIT Compiler eine wesentlich höhere
Ausführungsgeschwindigkeit. Ziel der JIT Compiler ist es dabei den
Maschinencode möglichst schnell, nicht jedoch möglichst schnellen
Maschinencode zu erstellen. JIT Compiler übersetzen grundsätzlich
den gesamten zur Verfügung1 stehenden Bytecode. Dies hat zur Folge,
dass JIT Compiler einen sehr hohen Speicherplatzbedarf haben.

HotSpot Compiler sind erweiterte JIT Compiler. Sie haben zusätzlich
zum JIT Compiler die Möglichkeit den Maschinencode zu Überwachen
und ggf. eine optimierte Neuübersetzung des Maschinencode zu
veranlassen. In diesem Zusammenhang arbeitet der HotSpot Compiler
wie ein Profiler, welcher die Auswertung und Änderung des geprüften
Anwendungsteils übernimmt. Zudem hat der HotSpot Compiler eine
altersbasierende Garbage Collection. D.h. während kurzlebige Objekte
schneller aus dem Speicher entfernt werden bleiben länger und
langlebige Objekte im Speicher. Dies ermöglich dem HotSpot Compiler
derartige Objekte schneller zu erzeugen. Durch die Tatsache, dass der
HotSpot Compiler den bereits erstellten Bytecode ständig überprüft
und ggf. neu übersetzt, ist er statischen / nativen Compilern in diesem
Punkt überlegen