JavaNativeCompiler

[KartoffelKiffer]

Hallo,

ich bekomme immer wieder von Kollegen und Bekannten zu hören: "Java ist doch viel zu langsam - Faktor 1:4; Benötigt die JVM, die installiert werden muss (...)". Logisch, ein gewisses Defizit ist bedingt durch die Interpretation der JVM. Der Bytecode kann nicht sofort von der Maschine gelesen werden, die JVM muss installiert sein.

Daher geht sicherlich ein Punkt an C++ und Konsorten, die ihre Binaries in kompillierter Form ablegen.

Auch Java kann diese Technologie mittels JavaNativeCompiler (JNC) nutzen.

Dort wird lediglich der Bytecode in gewöhnlichen Maschinencode übersetzt, was die JVM überflüssig macht. Lediglich am zu übersetzenden Rechner muss diese vorhanden sein.

Eine exe mittels JavaNativeCompiler kompilliert ist scheinbar groß, im Gegensatz zu einem gewöhnelichen QT-Projekt aber noch im Rahmen. Es werden in die exe halt auch alle benötigten Libraries eingebettet.

Jetzt meine eigentliche Frage: Hat wer von Euch Erfahrungen mit dem Compiler gesammelt? Positive, negative?

Wie ist der Vergleich zu einem hingehend gleichen C-Programm in sachen Performance?

Wird der Compiler sich mal mehr verbreiten? Ich meine, damit ist doch die Möglichkeit gegeben, endlich auch "richtige" ausführbare Dateien und Programme zu schreiben, die kein weiteres Installieren einer JVM nachsich ziehen.

Über Meinung würde ich mich sehr freuen.



Mfg
Tom

 

[Wildcard]

Glaubst du jeden Mist den man dir erzählt?

 

[KartoffelKiffer]

Was genau meinst Du?

Die Geschichte mit den Behauptungen? Ich selber habe noch keine derartigen Vergleiche durchgeführt, alsdass ich felsenfest die Behauptung stehen könnte, Java ist genauso schnell wie C++.

Ich bin allerdings mehr als zufrieden mit meinen Programme, an Performance sowie Sicherheit.

 

[tuxedo]

Geht denn das schon wieder los? Ist der Virus "Java ist langsam" denn nicht bald ausgerottet?

Zur Geschwindigkeit von Java im vergleich zu anderen Sprachen gibts genug Infos im Netz. Sofern du nichgt noch mit Java <1.4 arbeitest gibts da keine Probleme. Auch kann die JVM Bytecode-Programmteile zur Laufzeit noch optimieren, was bei nativen Programmen nicht mehr der Fall ist.

Wenn du zufrieden mit Geschwindigekt und Sicherheit bist: Warum rennst du dann dem Gelaber von anderen nach?

- Alex

 

[tfa]

Deine Bekannten sind offensichtlich nicht mehr auf dem neuesten Stand. Mittlerweile gibt es JIT-Compiler (Stichwort Hotspot). D.h. Java wird nicht mehr nur interpretiert, sondern das Programm oder Teile davon werden während der Laufzeit in Maschinen-Code übersetzt und ausgeführt. Es sind hier sogar laufzeitabhängige Optimierungen möglich, die ein AOT-Compiler nicht zu stande bringen kann.
Ich bin sicher, dass in der Vergangenheit sehr viel mehr in die Verbesserung von JIT-Compilern als in AOT-Compiler für Java investiert wurde. Dass eine "Java-EXE" schneller ist als die JVM, wage ich daher zu bezweifeln.
Wenn es Dir nur um die Geschwindigkeit geht, vergiss die nativen Compiler.

Hier ein Vergleich C++/Java: Benchmark (keine Ahnung, ob der was taugt). Der Geschwindigkeitsvorteil von C++ ist nicht besonders groß bei den meisten Tests. In einigen ist Java sogar schneller.

 

[kika]

Aber gerade das optimieren des Codes kostete Zeit und diese stört doch manchmal sehr. Man merkt dieses manchmal wenn man
eine neue Funktion in seinen Programmen aufruft, zumindest war es bei meinen Programmen unter Java 1.4 damals so. Zugegeben nach der Optimierung ist er schnell, oder schreiben die neuen Compiler
den optimierten Code auf die Festplatte, das könnte ja noch was bringen.

 

[tuxedo]

Als Java 6 raus kam, hat die c't berichtet, dass der JEditor allein durch das einfache compilieren mit Java6 etwa 50% schneller ausgeführt/gestartet werden konnte, verglichen mit dem Java 5 compilat.

"Damalige" Erfahrungen mit Java 1.4 sind also nicht mit dem aktuellen Stand vergleichbar. Ich glaube nichtmal annähernd vergleichbar.

- Alex

 

[Wildcard]

Ich bin allerdings mehr als zufrieden mit meinen Programme, an Performance sowie Sicherheit.

Über was diskutieren wir dann?

 

[KartoffelKiffer]

Es geht darum ein bereits von mir geschriebenes Programm in C++/QT neu zu entwickeln.

Der Grund: "C++ ist einfach stabiler, fühlt sich besser an, benötigt keine JVM, ist schneller".

Dagegen habe ich mich zu behaupten, ich junger Spund gegen einen erfahrenen C++-Programmierer.

Ich will nicht rumtrollen oder dergleichen, ich hoffe das merkt man, ich muss mich nur gegen Behauptungen stemmen, die auf den ersten Moment Hand und Fuß haben, bei näherer Betrachtung aber stellen sich bei mir die Nackenhärrchen kerzengerade nach oben.

Z.B. wird behauptet "Es gibt unter C++ zwar diese Probleme mit dem Speicherüberlauf etc. aber so wird man wenigstens sofort auf seine Fehler aufmerksam gemacht".

Sieht man dann im Schlusslicht, das Programm stürzt bei der kleinsten Unebenheit ab.

Gut, das einzige Argument, das gegen Java spricht, ist das Installieren der JVM. Es ist eigentlich eine Sache von zwei Minuten das JRE aufzuspielen, aber das geht meinem Kollegen schon zuwider. Wer suchet der findet, auch bei Java.

Den Benchmark in Verbindung mit der Aussage "In einigen ist Java sogar schneller." kann ich allerdings nicht verstehen. Was der Benchmark zeigt, ist eine derart deutige Dominanz der Sprache C++/C gegenüber jeglichen Kontrahenten (einige wenige ausgenommen), alsdass ich einen Vorsprung bei Java sehe. Eher im Gegenteil.

 

[tuxedo]

Du musst auf der Benchmarkseite nur nur die Grafik anschauen. Schau in das Tabellenartige Ding. Da gibts nur 2 Punkt wo C++ deutlich dominiert. Alles andere liegt meist im 1.x Fach bis 2.x Fachen Bereich.

Man muss auch noch dazu sagen: Besser ein guter Java Programmierer wie ein schlechter C++ Programmierer. Nur wer die Sprache ausschöpft kann auch performante Programme schreiben.

Die JRE musst du übrigens nicht zwingend installieren. Du kannst die JRE auch direkt mit deinem Programm ausliefern und beim start deines Programms die mit ausgelieferte JRE benutzen.
Somit fällt das Argument "Ich muss ja erst noch Java installieren" wieder weg.
Und die paar MB für die JRE fallen bei der größe von heutigen Programmen (man betrachte nur mal wie groß der AcrobatReader mittlerweile ist) nicht mehr ins Gewicht.

Vermeintliche Programmierer die sich so massiv und pauschal gegen eine Sprache stellen find ich mal mega-assi. Ein vernünftiger Programmiereroder Softwareentwickler beherrscht mehr als eine Sprache und kennt die jeweiligen stärken und schwächen. Java so als "Kinderspielzeug" abzustempeln find ich nicht okay. das ist fast schon unseriös und ignorant.

- Alex

 

[tfa]

Es geht darum ein bereits von mir geschriebenes Programm in C++/QT neu zu entwickeln.

Der Grund: "C++ ist einfach stabiler, fühlt sich besser an, benötigt keine JVM, ist schneller".

Dagegen habe ich mich zu behaupten, ich junger Spund gegen einen erfahrenen C++-Programmierer.

Worum geht's denn in dem Programm? Eine aufwendige Bildverarbeitung, Mustererkennung, Ray-Tracing oder 3D-Ballerspiele sollte man wirklich lieber in C/C++ entwicklen.

Für "normale" Desktopanwendungen (ganz zu schweigen von der Serverseite) hat C/C++ meiner Meinung nach keine Berechtigung mehr. Hier ist man mit modernen Plattformen wie Java oder .NET besser bedient. Das ist stabiler, fühlt sich besser an und ist viel schneller (die Entwicklung, nicht das Programm).

Ich will nicht rumtrollen oder dergleichen, ich hoffe das merkt man, ich muss mich nur gegen Behauptungen stemmen, die auf den ersten Moment Hand und Fuß haben, bei näherer Betrachtung aber stellen sich bei mir die Nackenhärrchen kerzengerade nach oben.

Z.B. wird behauptet "Es gibt unter C++ zwar diese Probleme mit dem Speicherüberlauf etc. aber so wird man wenigstens sofort auf seine Fehler aufmerksam gemacht".

Sieht man dann im Schlusslicht, das Programm stürzt bei der kleinsten Unebenheit ab.

Und was macht Dein Kollege dann? Lässt er sich per EMail einen 20MB großen Core-Dump schicken?
In Java bekommt man aussagekräftige Fehlermeldungen und Stacktraces mit Zeilenummern. Was für ein Fortschritt!
Frag ihn mal, ob er automatische Unit-Tests hat. Zeig ihm, wie man mit Eclipse die laufende Applikation beim Debuggen verändern und dann weiter Debuggen kann. Was ist mit der Plattformunabhängigkeit oder automatischen Speicherverwaltung?

Einige leben halt in ihrer alten Welt und wissen gar nicht, was ihnen entgeht.

Den Benchmark in Verbindung mit der Aussage "In einigen ist Java sogar schneller." kann ich allerdings nicht verstehen. Was der Benchmark zeigt, ist eine derart deutige Dominanz der Sprache C++/C gegenüber jeglichen Kontrahenten (einige wenige ausgenommen), alsdass ich einen Vorsprung bei Java sehe. Eher im Gegenteil.

Dann schau es Dir nochmal genau an. In zwei Tests ist Java 1,6 bzw. 1,7 mal so schnell verglichen mit C++.

 

[bronks]

... Der Bytecode kann nicht sofort von der Maschine gelesen werden, die JVM muss installiert sein.

Daher geht sicherlich ein Punkt an C++ und Konsorten, die ihre Binaries in kompillierter Form ablegen ...

Auch diese Zeiten sind schon vorbei. Es gibt nur noch sehr selten C++ Programme, die maschinenverständlich kompiliert sind. Eigentlich brauchen diese ebenfalls immer Ihre Runtime in Form von Libs und Dlls. Bei Java ist das eine VM, welche noch im laufenden Betrieb Optimierungen vornimmt.

 

[robertpic71]

Den Benchmark in Verbindung mit der Aussage "In einigen ist Java sogar schneller." kann ich allerdings nicht verstehen. Was der Benchmark zeigt, ist eine derart deutige Dominanz der Sprache C++/C gegenüber jeglichen Kontrahenten (einige wenige ausgenommen), alsdass ich einen Vorsprung bei Java sehe. Eher im Gegenteil.

Du musst auf der Benchmarkseite nur nur die Grafik anschauen. Schau in das Tabellenartige Ding. Da gibts nur 2 Punkt wo C++ deutlich dominiert. Alles andere liegt meist im 1.x Fach bis 2.x Fachen Bereich.

Was die Benchmarks angeht, muss ich KartoffelKiffer recht geben: Java unterliegt bei fast allen Benchmarks (15 von 17).

Zur Tabelle:
schwarz geschriebene Faktoren: C++ besser
grau geschriebene Faktoren: Java besser

Die einzige Spalte wo es für Java leichte Vorteile gibt, ist die Sourcegröße (GZipBytes). D.h. für die Javabenchmarks ist weniger Sourcecode erforderlich, als für die C++ Benchmarks - die Unterschiede sind allerdings gering.

Fakt ist: Wenn es nur um reines Benchmarking geht, unterliegt Java vielen Sparten gegenüber C++. Auf der anderen Seite ist Java um ein vielfaches schneller als z.B. PHP, Ruby, Phyton usw.

Fakt auch: Java braucht mehr Speicher. Die JVM fordert ihr Tribut: Der Betrieb eines (Hotspot-)Compiler/Interpreters inkl. VM kostet eben auch Zeit beim Starten und braucht auch selber Hauptspeicher.

Jetzt aber zum praktischen Teil:
KartoffelKiffer: Frag deinen Bekannten warum er nicht in Assembler oder C programmiert? Ein guter Assemblerprogrammierer schafft sicher noch bessere Benchmarks....

Daran kann man schon erkennen: Performance ist nicht alles

Es wird zwar vielfach behauptet Java sei langsam, aber konkrete Beispiele bleiben meist aus. Das das VM-Konzept Vorteile bietet, sieht man auch daran, dass Microsoft die Architektur (DOT.NET) nachgebaut hat.

Klar ist eine VM für ein Desktopprogramm ein Malus. Bei kleinen Programmen braucht der Start der VM samt Compiler länger, als das eigentliche Programm. Gerade bei großen kommerziellen Anwendungen (1xTag starten) ist das aber überhaupt nicht das Thema.

Meiner Meinung nach, leidet Java noch immer unter dem schlechten Ruf, welcher mit den ersten JRE's (und der damligen) Hardware entstanden ist. Mit aktueller Hardware und Javaruntime gibt es mMn nichts zu meckern.

Über die vielen Vorteile will ich mich gar nicht auslassen, nur noch ein Zitat des H2-Programmierers (extrem schnelle JavaDatenbank):

Why Java
A few reasons using a Java database are:
• Very simple to integrate in Java applications
• Support for many different platforms
• More secure than native applications (no buffer overflows)
• User defined functions (or triggers) run very fast
• Unicode support
Some people think that Java is still too slow for low level operations, but this is not the case (not any more). In general, the code can be
written a lot faster than using C or C++. Like that, it is possible to concentrate on improving the algorithms (that make the application faster)
rather than porting the code and dealing with low level stuff (such as memory management or dealing with threads). Garbage collection is now
probably faster than manual memory management.
A lot of features are already built in (for example Unicode, network libraries). It is very easy to write secure code because buffer overflows and
such problems can be detected very easily. Some features such as the reflection mechanism can be used for randomized testing.

/Robert

[Edit]
Nachtrag zum eigentlichen Thema:
1.) Die Programme vom, nativen Javacompiler GCJ, laufen langsamer als in der JRE. Auch von den anderen habe ich nichts gutes gehört.
2.) Um auch den "einfachen" Windowsuser mit einer exe-Datei glücklich mach zu können, empfiehlt ein Exe-Wrapper wie z.B. JSmooth. Dort kann man auch dir JRE prüfen lassen bzw. auf eine Installationsdatei verweisen lassen (Url oder File beilegen). Die Exe ich lege zusätzlich dazu. Für andere Betriebssysteme gibts ja noch die Jar-Datei.
[/Edit]

 

[Wildcard]

Nicht vergessen, ein Microbenchmark macht keine Applikation.
Nimmt man sich kleine Algorithmenschnippsel ist eine nativ kompilierte Sprache in den meisten Fällen schneller und hat definitiv einen kleineren Footprint.
Doch wieviel % der Laufzeit einer echten Applikation fallen auf den algorithmischen Teil (den man im extremfall bei einem Java Programm nativ auslagern könnte) und wieviel auf komplett andere Aufgaben?
Wo bleiben die Benchmarks die komplexe Applikationen gegenüberstellen?
Wie sieht die Sache aus wenn man die größeren Freiheiten beim Speichermanagement auf C Seite nicht mehr wirklich nutzen kann, weil sich bei 1.000.000 Zeilen Code kein Mensch mehr die mühe macht?

 

[tuxedo]

Du musst auf der Benchmarkseite nur nur die Grafik anschauen. Schau in das Tabellenartige Ding. Da gibts nur 2 Punkt wo C++ deutlich dominiert. Alles andere liegt meist im 1.x Fach bis 2.x Fachen Bereich.

Was die Benchmarks angeht, muss ich KartoffelKiffer recht geben: Java unterliegt bei fast allen Benchmarks (15 von 17).

Zur Tabelle:
schwarz geschriebene Faktoren: C++ besser
grau geschriebene Faktoren: Java besser

Ähm, hast du dir die Tabelle mal genau angesehen? Wie hoch schätzt du den Vorteil wenn C ganze 1,1-1,5x schneller ist als Java?

Die im Benchmark einzig wirklichen Vorsprünge für C++ sind die hier:

k-nucleotide 2.2x
nsieve-bits 1.9x
reverse-complement 4.9x
meteor-contest 10.8x
startup 41x

Der Rest bewegt sich im Rahmen von 1.0 bis 1.5x, und das ist, wenn man Wildcards einwand bzgl. der Mikrobenchmarks hinzunimmt, nicht mehr wirklich relevant oder irgendwie spürbar. Von 17 Tests ist C++ nur in 6 Fällen mit einem gewissen Vorsprung schneller. Und das mit dem "startup" ist für mich eh vernachlässigbar. Denn wie oft starte ich denn deine Benutzer-Anwendung pro Tag neu? Ganz tolle Wurst. Wechseln wir also alle zu C++ oder wie?

Jedem das seine. Ich mag Java so wie es ist. Solange ich nicht auf niedrigster Hardwareebene was machen muss seh ich für mich keinen Grund von Java abzusehen. Und wozu gibts denn JNI oder JNA? Auf Netzwerkebene hat das Linage2-MMORPG-Serverprojekt (l2j.sf.net) bewiesen dass es mit seeeehr vielen Clients zurecht kommt (es gibt Server mit 2500-5000 Spielern ...). Also auch hier ist Java kein Kinderspielzeug, sondern ein ausgewachsenes System.

Im übrigen kann ich Wildcard nur voll und ganz zustimmen. *zustimm*

Just my 5 cent ..

- Alex