Java 5 - Performance und Vergleich zu C++

[h2owasser]

Designtechnisch kann man sehr viel aus Java rauschholen, da kann C++ nicht ganz mithalten, daher denke ich das Java auch bald für C++ ein bisschen gefaehrlich werden kann.

Kannst du mir dafür mal ein Beispiel nennen ?

In sehe aktuell C(++) immernoch für die universellste Sprache, die nur nach unten durch Assembler und oben durch Java, Php, und was weis ich (web) begrenzt wird. Aber selbst da läßt sich C(++) zum Teil hinbringen.

 

[Locke]

Java dürfte zum teil C++ in Sachen performance schlagen. Die VM is recht gut optimiert und wird gut weiterentwickelt, des weiteren is das Objektmodell in Java wesentlich schlanker. Bin mal gespannt wie das mit 1.5 aussieht.

 

[miketech]

Hi,

naja C# ist ja eher die Reaktion von Microsoft auf Java. Ich denke, dass C# auf Windowsplattformen eine echte Chance hat. Microsoft wird .NET von Haus aus mitliefern (keine zusätzliche Installation einer VM nötig, wie bei Java) und C# bietet alle Funktionen, die man für Windowsprogrammierung benötigt. Hier müssen auch keine Einschränkungen gemacht werden, da C# nicht als plattformunabhängige Sprache von Microsoft geplant war. Auf Linux/Unix sehe ich für C# jedoch einen noch schweren Weg, es seidenn die Windowsprogramme sollen auch unter Linux/Unix laufen.

Insgesamt bin ich jedoch der Meinung: Wenn schon sowas wie Java und C#, dann Java.

Gruß

Mike

 

[h2owasser]

Java dürfte zum teil C++ in Sachen performance schlagen. Die VM is recht gut optimiert und wird gut weiterentwickelt, des weiteren is das Objektmodell in Java wesentlich schlanker. Bin mal gespannt wie das mit 1.5 aussieht.

Das kann ich irgendwie nicht glauben. Wie soll Code, die interpretiert wird, schneller sein als direkt compilierter Code. d.h. guter Code muss in C++ doch schneller sein, oder wo ist mein Denkfehler ?

 

[miketech]

Hi h2owasser,

die Java VM kompiliert den Code ja vor Ort (JIT) und passt Ihn optimal auf die darunterliegende Plattform an. Wenn also der C++ Code nicht auf die Plattform optimiert kompiliert wurde kann es sogar sein, dass das Java-Programm in der Ausführung etwas schneller ist.

Gruß

Mike

 

[miketech]

Ergänzung: Das würde natürlich bedeuten, dass man in Java lediglich bei GUIs in der Performance noch hinterherhängt (wer weiß, wie das bei Java 5 aussieht) und sonst nur in den Möglichkeiten, die eine Sprache, wie Java nicht bieten kann. Denn Java kann nicht alles bieten, was eine Sprache, wie C++ zur Verfügung stellt, wenn für eine Plattform entwickelt wird. Denn dann stehen mir außerdem Dinge wie Prozesssteuerung, Dateisystemoperationen (Rechteverwaltung usw.) zur Verfügung, die mit Java nicht möglich sind, da hier darauf geachtet werden muss, dass nur die Operationen implementiert werden, die auf allen unterstützten Plattformen zur Verfügung stehen.

Gruß

Mike

 

[etuli]

die Java VM kompiliert den Code ja vor Ort (JIT) und passt Ihn optimal auf die darunterliegende Plattform an. Wenn also der C++ Code nicht auf die Plattform optimiert kompiliert wurde kann es sogar sein, dass das Java-Programm in der Ausführung etwas schneller ist.

Die Java VM ist aber selbst nicht optimal an das System angepasst. Das heisst, egal wie gut der Java Code optimiert wurde, die VM wird ihn nicht besser ausfuehren, als sie selbst optimiert wurde.

Und mal angenommen die VM ompiliert den Code Just in Time vor Ort. Wie lange dauert es dann etwa OpenOffice zu starten? DIe kompilierung in C++ dauert auf schnellen System um die 8 Stunden.

Java ist nicht schneller als C++.

 

[miketech]

Der Start von Anwendungen dauert ja generell länger, da die VM erst gestartet werden muss. Aber sonst ergeben Deine Argumente natürlich schon Sinn, da das Kompilieren ja auch Zeit braucht. Demnach kann eine interpretierte Sprache ja nie schneller sein, als eine Binary oder?

Gruß

Mike

 

[etuli]

Demnach kann eine interpretierte Sprache ja nie schneller sein, als eine Binary oder?

Eine Binaerre Sprache wird direkt vom Prozessor abgearbeitet. Eine Interpretierte Sprache, ob in Byte-Code, oder nicht, wird selbst wieder von einem Programm abgearbeitet, welches wiederrum Binaer abgearbeitet wird.

Es kann sicher Beispiele geben, wo die VM anderen Code eventuell effizienter ausfuehrt, als Binaer optimierter Code. Aber stellen diese dann Ausnahmeerscheinungen dar.

mfg

 

[ExRevel]

@h2owasser... ich persoenlich finde das die oo syntax von java wesentlich ausgereifter ist, auch das ganze oo-model. Dadurch das Java so neu ist konnte es von den Fehlern die bei anderen OO-Sprachen evtl. gemacht wurden nur profitieren. Leute die Eiffel schreiben sagen das ueber die sprache nix ruebergeht, aber ich habe nie damit programmiert und so ist fuer mich Java schon das optimum an OOP. Sachen wie mehrfachvererbung die probleme buergen gibt es nicht, das wurde "geschickter" geregelt. Der ganze Klassenaufbau ist ganz nett, wenn er auch auf den einsteiger verwirrend wirkt, dennoch kann man eine klassenreferenz im internet anschaun, zu C++ gibt es nur sehr wenige kompetente homepages.

Ich muss ja nun auch gestehen das ich den Server meines Projekts in C++ und nicht in Java schreibe weil ich ein bissal sorge habe das ich aus dem Performanceloch von Perl sonst net rauskomme, wobei die Angst sicher unbegruendet ist, da ich nicht dauernd Stringhandling brauche, wo javas "schwaeche" liegt.

 

[hehejo]

Und mal angenommen die VM ompiliert den Code Just in Time vor Ort. Wie lange dauert es dann etwa OpenOffice zu starten? DIe kompilierung in C++ dauert auf schnellen System um die 8 Stunden.

ABER: Es wird ja nicht der Java-Sourcecode kompiliert sondern nur der Bytecode. Sonst wäre das wohl alles unzumutbar

 

[Locke]

ihr solltet mal mehr über compiler lesen beziehungsweise damit arbeiten.
die vm kann mies optimiert sein, solange sie maschinenspezifisch optimalen code aus dem bytecode umsetzt ist die optimierung der vm irrelevant.
des weiteren kann ein compiler nur statische informationen im compileprozess verwenden, er kann nicht anhand von laufzeitprofilen code optimieren, lediglich kleine profiles sind möglich. eine vm kann jederzeit den code umstrukturieren und damit einige branches besser auslasten.
code optimierung ist kein einfaches feld, lediglich den code in asm umzusetzen is es nicht, zb loop unrolling oder data prefetching sind felder in denen eine vm wesentlich besser optimieren kann.
natürlich kostet das profiling in runtime sowie das echtzeitübersetzen und ausführen zeit, aber durch gute optimierungen kann dies durch den optimierungsgewinn wieder aufgefangen werden.

 

[h2owasser]

@Locke. Cool, klingt einleuchtend. Den Faktor hab ich so nicht gesehen. Dann kann aber C/C++/C#(Mono) wirklich alles... haha *g*... Na, solange ich mich mit (einfachen) grafischen Simulationen befasse und diese noch schnell genug sind, bleib ich erstmal bei C++. - Bin ja kein Informatiker.

 

[miketech]

Also verstehe ich das richtig, dass der Vorteil der VM darin liegt, dass sie den Code "intelligent" verwalten kann?

Vielleicht eine blöde Frage, aber kann der Betriebssystemkern dann nicht ähnlich mit Binaries umgehen?

Wenn also eine VM den Code dadurch noch zusätzlich optimieren kann, sollte doch der Kernel auch in der Lage sein, dies mit Binaries zu tun oder?

Kann es möglich sein, dass eine VM immer schneller Byte-Code ausführt als der Kernel das Binary? Theoretisch müsste doch die Binary in allen Bereichen immer genauso schnell oder schneller sein können.

Gruß

Mike

 

[miketech]

@ExRevel:

Das hört sich so an, als ob Du Java immer C++ vorziehen würdest, wenn sich die Anwendungszwecke von Java und C++ decken?

Gruß

Mike

 

[etuli]

ihr solltet mal mehr über compiler lesen beziehungsweise damit arbeiten.
die vm kann mies optimiert sein, solange sie maschinenspezifisch optimalen code aus dem bytecode umsetzt ist die optimierung der vm irrelevant.
des weiteren kann ein compiler nur statische informationen im compileprozess verwenden, er kann nicht anhand von laufzeitprofilen code optimieren, lediglich kleine profiles sind möglich. eine vm kann jederzeit den code umstrukturieren und damit einige branches besser auslasten.
code optimierung ist kein einfaches feld, lediglich den code in asm umzusetzen is es nicht, zb loop unrolling oder data prefetching sind felder in denen eine vm wesentlich besser optimieren kann.
natürlich kostet das profiling in runtime sowie das echtzeitübersetzen und ausführen zeit, aber durch gute optimierungen kann dies durch den optimierungsgewinn wieder aufgefangen werden.

Stimmt ja (fast) alles, was du sagst. Aber die effizienz steht relativ zu interpretierten Ausfuehrung. Nicht einer Kompilierten. Die Kompilierung von Code wird in einer VM fuer gewoehnlich danach entschieden, ob es sich lohnt den Code interpretiert auszufuehren, oder ihn zu kompilieren. In diesem Kontext wird dann ueber den Grad der Optimierung entschieden.

Bei der kompilierung eines Programms in C++ spielen solche Ueberlegungen hingegen keine Rolle. Es wird vorausgesetzt, dass die Kompilierung des Gesamten den Nutzen des Aufwands spaeter in der Ausfuehrung abwiegt.

Optimierung einer VM fuer etwa Java kannst du demnach nicht mit einer voll-kompilierten Sprache wie C++ vergleichen. Das kannst du mit anderen Sprachen machen, wie etwa Perl, oder PHP, welche ebenfalls interpretiert werden.

Also: Die VM kompiliert, wenn sie auf Grund einer "Kosten-Nutzen-Rechnung" meint, dies wuerde effizienter sein, als eventuell mehrmals Byte-Code zu interpretieren. Da C++ aber immer kompiliert und optimiert wird, und sich die Frage nach interpretation nicht stellt, kann man eine VM nicht mit einer voll-kompilierten Sprache vergleichen.

mfg

 

[Locke]

klar hinkt der vergleich. aber compilieren heisst nicht automatisch den bestoptimierten code zu erhalten, da der compiler nicht weiss, wie das programm später genutzt wird, er kann nur anhand des codes entscheiden und heuristiken verwenden. zb is vektorisierung und parallelisierung recht schwierig im compiler optimal zu lösen, da liegen eher die stärken von vms. daten im cache zu halten anhand ihre nutzung is wesentlich effizienter als einfach mal alle kleinen funktionen in den cache zu kloppen und arrays zu prefetchen, genau das macht aber dein statischer compiler, er kanns auch net anders, er weiss ja nicht was davon wie oft und wann genutzt wird.
genausowenig kann er nicht alles was nur readonly zugegriffen wird als statisch annehmen sondern muss skalarisieren. sowas kostet performance. und ja die vm interpretiert meisst und entscheidet nur bei bestimmter last den jit anzuschmeissen, was aber nicht heisst dass diese methodik soviel lahmer sein muss. konzeptionell wird da noch einiges kommen. statische compiler haben ihre stärken in statischem code, mit möglichst wenig conditionals, während vms auf laufzeitverhalten wesentlich besser reagieren können. in der praxis tun sie das nicht immer, die jvm is auch nicht der weisheit letzter schluss, aber schon recht gutes stück code.

 

[ma-games]

Ich werd mir die Java-Version 5 mal holen wenn sie komplett fertig ist. Mal sehn ob ich dann einen Performnce-Vorteil zu den älteren Version festellen kann. Weil bis zu 30 mal schneller wie es angekündigt wurde? Das müsste man dann eigentlich merken!

 

[etuli]

konzeptionell wird da noch einiges kommen.

Ich bin weder ein VM Entwickler, noch ein Compiler Entwickler, weshalb ich als Nutzer nur den aktuellen Zahn der Zeit betrachte. Es wird noch vieles kommen. Streite ich auch nicht ab. Aber es ist noch nicht da und ob die heutigen Ansaetze dann spaeter noch eine Aehnlichkeit zu den dann aktuellen Umsetzungen kennen werden, wage ich zu bezweifeln. ;o)

mfg

 

[ExRevel]

@miketech, naja, Java ist die komfortablere Sprache und wenn ich nicht grad wie ein dummer meinen Source tunen muss (was meiner Meinung nach mit C++ natuerlich noch besser geht als mit Java), dann ziehe ich Java vor, ja!