Warum Java vom Prinzip her schneller als C++?
-
Verwirrter schrieb:
Man hört ja immer wieder dass Java vom Prinzip her schneller sei als C++. Ich verstehe das nicht so ganz eigentlich müsste Java doch langsamer sein da eben noch die VM dazwischenliegt?
Liegt es vielleicht daran dass die Sprache Java zb einfacher ist und darum der Compiler für Java darum auch besser optimieren kann?Wär super wenn mich da jemand aufklären könnte
Die VM ist nicht prinzipiell ein Grund, warum Java-Programme langsamer sein müssen. In der Praxis ist das momentan der Fall, relativiert sich aber immer mehr.
Mit entscheidend für die Performance eines Programms ist, wie gut ein Compiler optimiert. Bei Java kann der Compiler i.d.R. sehr viel genauere Annahmen darüber machen, wie eine Variable oder ein Objekt benutzt wird und u.U. besser optimieren. In C++ hat der Programmierer viele Freiheit, so dass der Compiler oft konservativer optimieren muss.
-
Java kann den Code zur Laufzeit optimieren. C++ nur zur Compile-Zeit.
-
Naja, mit Microsofts neuer Profile Guided Optimization-Technik (PGO) wird genau das was der JIT kann, versucht nachzuahmen. Laut MS hat das PGO den MS SQL Server im Schnitt 30% schneller gemacht, nur durch Neukompilierung. Das PGO selbst arbeitet nach dem Prinzip, das es nach dem Kompilieren versucht in einem Programmlauf zu analysieren, wie der Programmablauf am häufigsten sein könnte. Also z.B. welche cases in switch-Blöcken am häufigsten aufgerufen werden u.ä. Dann wird _nochmal_ mit den neuen Laufzeit-Erkenntnissen compiliert und verlinkt. Das was der JIT von Java zur Laufzeit in Realworld macht, hat MS einfach an die C++ Gegebenheiten übertragen. Ziemlich clever!
Also auch im C++ Compilerbau ist noch viel Potential. Zumindest hat MS mit ihrem VC++2005 gezeigt, das man noch was rausholen kann. Sicherlich werden auch noch andere Compiler-Hersteller ein paar Techniken aus dem Hut zaubern, die C++ noch weiter optimieren können. Immer dann, wenn man glaubt, das Maximum ist erreicht, kommt doch noch was neues. Zumal MS selbst ja ihr komplettes Windows und viele Produkte, wie SQL Server, mit dem eigenen Compiler compilieren muß, werden sie die Sache nicht einfach einschlafen lassen.
Ich sehe es nicht, das Java das C++ in nächster Zeit überholen wird. Ich kann mir nur vorstellen, das man C++ einholen wird... aber das kann ich aus meiner täglichen Java-Praxis mit 3000 Usern nicht erkennen. Jede neue Java VM bringt _spürbar_ mehr Performance, keine Frage. Aber C++ Programme sind einfach schneller, vorallem in Massendatenverarbeitung.
Achja, hier der Bericht zu MS' aktuellen optimierenden Compiler:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/profileguidedoptimization.asp
-
Sehe ich genauso. Ich glaube zwar an den theoretischen Vorteil bei Sprachen wie Java, aber da wird noch einige Zeit in's Land ziehen. Und nicht zuletzt hat man in C++ immer die Möglichkeit, mit mehr low-level und 300fachen Aufwand nochmal 5% mehr rauszuholen.
Ich denke aber, dass für viele Anwendungen der Unterschied in Zukunft irrelevant wird.
-
Verwirrter schrieb:
Man hört ja immer wieder dass Java vom Prinzip her schneller sei als C++.
Naja, es ist eine falsche Aussage, wenn man sagt, dass Java vom Prinzip her schneller als C++ sei. Realistischer ist folgende Aussage: Java könnte vom Prinzip her in bestimmten Situationen bestimmte Codeteile schneller ausführen als ein C++-Programm ausgeführt wird. Diese Aussage gilt aber natürlich auch andersherum. Wenn man soetwas pro-Java sagt, dann bezieht man sich meistens darauf, dass Java Optimierungen zur Laufzeit durchführen könnte, die ein C++ Compiler nicht zur Compilezeit durchführen kann. Zum Beispiel Inlining bei vorhandener Laufzeitpolymorphie. Aber das ist nur ein ganz theoretischer Aspekt. In Wirklichkeit wird bei Java sehr sehr wenig optimiert. Es gibt zum Beispiel noch keine Vektorisierungsoptimierungen:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340864
Etwas, was bei C++ schon da ist.
Auch der Stack wird noch nicht so ausgenutzt, wie er genutzt werden könnte:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6336351
...also keine Lösung für ein Performanceproblem, das man bei C++ so gar nicht hat.
Mit anderen Worten: Man holt bei Java längst nicht das raus, was man rausholen könnte. Und diese Feststellung bezieht sich sicher nicht nur auf Java. Bei C++ wird es genauso aussehen. Die Compiler, die man hat, liefern halt keine perfekten Ergebnisse. Und insofern sollte man da von solchen theoretischen Betrachtungen, wie sie bezüglich der Performance oft vorgebracht werden, eher absehen. Die theoretischen Möglichkeiten werden einfach nicht erreicht und es ist eher die Frage, wer näher an diese herankommt. Man muss also nachmessen, sonst kann man in diesem Umfeld keine sinnvollen Aussagen treffen.
-
Ich lach mich schlapp! Einige von euch glauben wirklich, der javac würde optimieren??! Schonmal den assemblierten Code analysiert? Also javac ist leider dumm wie Brot. Aber wie extrem dummes Brot.
Mag ja sein, dass die RTE einiges rausschlagen kann, aber der erste Schritt zur vernünftigen Optimierung, ist doch ein optimierender Compiler.
-
Wollt nur mal sagen schrieb:
Ich lach mich schlapp! Einige von euch glauben wirklich, der javac würde optimieren??! Schonmal den assemblierten Code analysiert? Also javac ist leider dumm wie Brot. Aber wie extrem dummes Brot.
Mag ja sein, dass die RTE einiges rausschlagen kann, aber der erste Schritt zur vernünftigen Optimierung, ist doch ein optimierender Compiler.Du irrst dich. Das ist bewusstes Designziel, dass der javac nicht optimiert. Der javac hat u.U. weniger Informationen zur Verfügung als die Laufzeitumgebung, deshalb macht die das.
-
ein weiterer vorteil von java ist, dass der code plattformspezifisch optimiert werden kann. sprich: auf einen pc unter windows wird so optimiert, wie es unter windows auf einem pc am besten und schnellsten laufen kann und auf einem mac wird anders optimiert. in c++ müsste man nicht nur für jede plattform neu kompilieren, sondern höchstwahrscheinlich auch code für die entsprechende plattform ändern Λ
-
Das ist ja quatsch. Ich kann ganz einfach mit VC++ für jeden Prozessor speziell kompileren. Dann habe ich zwar z.B. drei EXE Dateien, kann aber beim Programmstart anhand der CPU-Erkennung entscheiden, welche EXE-Variante ich dem User laden soll. Davon würde der User nicht mal was mitbekommen. So hätte ich auch in C++ Programmen immer die optimale Variante.
Klar, der Entwickler muß einen Arbeitsschritt mehr machen. ABer um ehrlich zu sein, hat man schon sooo viel zu tun um dem User ein vernünftiges Programm zu bieten, das fällt dann auch nihct mehr ins Gewicht.
-
Artchi schrieb:
Das ist ja quatsch. Ich kann ganz einfach mit VC++ für jeden Prozessor speziell kompileren.
das sagte ich ja, dann darfst du für jede plattform neukompilieren. und mit vc++ kannst du schonmal gar keine binary für nen mac erzeugen können
aber auch das wird dir nicht die flexibilität geben können, wie wenn du direkt auf der zielplattform, auf der zielhardware und softwarekonfigurationen kompilieren kannst.
-
Roar schrieb:
Artchi schrieb:
Das ist ja quatsch. Ich kann ganz einfach mit VC++ für jeden Prozessor speziell kompileren.
das sagte ich ja, dann darfst du für jede plattform neukompilieren.
Egal, muss ich so oder so, werd meine Linux-Binary schwerlich auf Artchis Win32 zum Laufen kriegen
und mit vc++ kannst du schonmal gar keine binary für nen mac erzeugen können
Bald ist ja Mac auch Intel-Land, dann brauch ich den Code nur noch unter Mac kompilieren und alles ist in Ordnung.
-
Die Java-Fans können mir noch so viel von Komfort beim Ausliefern erzählen, das ich einfach nur sagen kann, das wichtiger ist, was beim User funktioniert. Ich habe schon seeeehr viel Erfahrung mit Java (seit 2001), habe bisher das 4. Java-Projekt am Hacken. Immer im Schnitt 3000 User im Konzern. Und scheiß auf das einfache einmal kompilieren, wenn z.B. Java 1.5 auf WinXP Pro SP2 auf manchen Druckern nicht funktioniert!!!
Vor zwei Wochen haben wir endlich auf Java 5 Runtime für unser aktuelles Projekt umgestellt. Tja, seit dem kann einer unserer User nicht mehr auf seinem Drucker drucken: Der Drucker weist den Druckjob ab, kommt als PrinterException. Nach einem ganzen Tag nach Fehlersuche, haben wir festgestellt, das er zur Zeit der einzige User mit SP2 ist. Jetzt braucht er wohl einen anderen PC.
Hey, das ist nicht das erste Mal das irgendwas nicht funktioniert, in Kombination mit Java. Da sag ich nur: mir bringt es nichts, wenn beim User Probleme auftauchen. Da nehme ich mir lieber die Zeit unc kompiliere einmal mehr für ein Release.
Ich finde, die Java-Fans sollten nicht immer so reden, als ob bei ihnen alles perfekt läuft. Denn das tun die Java-Fans immer. C++ ist immer umständlich und in Java geht alles angeblich wie von Geisterhand. Aber in Reallife sieht die Welt anders aus.
-
Artchi: Ist es eigentlich sehr deprimierend, wenn man die ganze Zeit mit einer Sprache arbeiten muss, die man so überhaupt nicht leiden kann? Ich meine, wenn es nach dir ginge, würdet ihr das doch alles mit C++ machen, oder? Wer bestimmt das denn bei euch? Wahrscheinlich die Leute, die keinerlei Ahnung von den verschiedenen Technologien haben, heh?
Inwiefern hälst du eigentlich C++ für die Anwendungsgebiete, die ihr da habt, besser geeignet? Meinst du, mit C++ kann es nicht vorkommen, dass irgendwo ein Drucker unter SP2 nicht funktioniert? Da glaube ich nicht so ganz dran.
-
Artchi schrieb:
Die Java-Fans können mir noch so viel von Komfort beim Ausliefern erzählen, das ich einfach nur sagen kann, das wichtiger ist, was beim User funktioniert. Ich habe schon seeeehr viel Erfahrung mit Java (seit 2001), habe bisher das 4. Java-Projekt am Hacken. Immer im Schnitt 3000 User im Konzern. Und scheiß auf das einfache einmal kompilieren, wenn z.B. Java 1.5 auf WinXP Pro SP2 auf manchen Druckern nicht funktioniert!!!
Vor zwei Wochen haben wir endlich auf Java 5 Runtime für unser aktuelles Projekt umgestellt. Tja, seit dem kann einer unserer User nicht mehr auf seinem Drucker drucken: Der Drucker weist den Druckjob ab, kommt als PrinterException. Nach einem ganzen Tag nach Fehlersuche, haben wir festgestellt, das er zur Zeit der einzige User mit SP2 ist. Jetzt braucht er wohl einen anderen PC.
Hey, das ist nicht das erste Mal das irgendwas nicht funktioniert, in Kombination mit Java. Da sag ich nur: mir bringt es nichts, wenn beim User Probleme auftauchen. Da nehme ich mir lieber die Zeit unc kompiliere einmal mehr für ein Release.
Ich finde, die Java-Fans sollten nicht immer so reden, als ob bei ihnen alles perfekt läuft. Denn das tun die Java-Fans immer. C++ ist immer umständlich und in Java geht alles angeblich wie von Geisterhand. Aber in Reallife sieht die Welt anders aus.
Klar gibt es mit Java auch Probleme. Aber ich hatte bis jetzt den Eindruck, dass es mit Java zumindest WENIGER Probleme bei den Endusern gibt als z.B. mit in C++ entwickelten Programmen.
-
Was ich in diesem Thread hier loswerden wollte: Meiner Ansicht nach hat "Wollt nur mal sagen" recht. Ihr werdet feststellen was er meint, wenn ihr mal get-Methoden in gestaffelten Schleifenaufrufen verwendet (z.B. DFT-Algo etc.). Ein C-Compiler optimiert sowas weg, da sich die initial-value nicht ändert. Javac hingegen, ignoriert das vollkommen. Und die (aktuelle) JVM optmiert das auch nicht weg. Da muss also noch einiges getan werden.
-
ich glaube die Java VM wird immer noch mit Visual C++ 6 compiliert!!!!!! (steht in nem Fehlerlog) das sollte sich auch mal ändern.
-
Gregor schrieb:
Artchi: Ist es eigentlich sehr deprimierend, wenn man die ganze Zeit mit einer Sprache arbeiten muss, die man so überhaupt nicht leiden kann? Ich meine, wenn es nach dir ginge, würdet ihr das doch alles mit C++ machen, oder? Wer bestimmt das denn bei euch? Wahrscheinlich die Leute, die keinerlei Ahnung von den verschiedenen Technologien haben, heh?
Es ist eher depremierend, das Java als Hyper-Super-Duper-Mega-geil dargestellt wird und C++ als C das zufällig ein Schlüsselwort class hat. Ich rede jetzt nicht speziell über dieses Forum, sondern das was mir in Reallife regelmäßig begegnet. Was meinte der Kollege (vor zwei Jahren von der TU Braunschweig gekommen) vor einem Monat zu mir: "Gibt es in C++ überhaupt eine Sortierfunktion?"
Das wahr keine sarkastische Frage, sondern eine ernste!Ich habe hier letzte Woche von EMS den neuesten SQL Manager installiert. Der sieht von der GUI her seeeeehr stylisch aus (ggü. der alten Version), also wirklich sehr bunt mit, Docking und haste nicht gesehen. Was meinte ein anderer Kollege zu mir, als er mich damit rumspielen sah? "Ist das die neue .NET-Version vom SQL Manager?"
Nein, es ist immer noch eine native Win32-Anwendung, die wahrscheinlich in C++ entwickelt wurde. Antwort vom Kollegen: "Hem, die GUI sieht mittlerweile so gut aus. Ich hätte jetzt gedacht das ist C#..."Ich möchte betonen, das es alles auch programmierer sind, die mir sowas an den Kopf knallen. Nur halt alle die kein C++ kennen.
So, jetzt stelle man sich vor, jemand kan garnicht programmieren. Was soll der dann über C++ denken???
Und ja, es sind Manager die die Konzernstandards (Sprachen, Frameworks, Datenbanken usw.) festlegen. Meistens spielen da keine technischen Gründe eine Rolle, sondern politische. Ich kann da Stories erzählen, da fällt ihr vom Stuhl! Wir haben erst letztens versucht Netbeans-Platform als Framework zu etablieren. Stattdessen wird ein Framework von einer braunschweiger Firma vom Konzern favoriesiert, wo zur Zeit EINE Person dran entwickelt. Natürlich hat die Firma ein Nachfolgeprojekt auf diesem Framework erhalten.Meine schöne Powerpoint-Präsi mit dem Netbeans-Eigenschaften wurde von den Konzern-Architekten mit dem Argument abgeschmettert: "Sie können mir noch so viele Vorteile nennen, das Framework ******** ist jetzt gesetzt." Mein Kollege fragt nach: "Aus welchen gründen?" Konzern-Architekt: "Es sind politische Gründe."
Es gilt auch folgende Regel: Es werden nur Produkte von Firmen eingesetzt, die mind. 25 Jahre auf dem Markt existieren. Datenbank-Produkte wie Poet, ObjektStore, Cache (Intersystems)... die ja wirklich himmlich für einen OO-Entwickler sind, haben aus einem Grund hier keine Chance: die Firmen sind nicht lange genug auf dem Markt. Deshalb wird nur IBM DB2 und Oracle eingesetzt. Egal ob schlecht oder veraltet. Konzernweit wohlgemerkt.
Java und andere Produkte werde nicht eingetzt, weil sie besser sind. Es spielen politische Gründe... sprich Geld.
Gregor schrieb:
Inwiefern hälst du eigentlich C++ für die Anwendungsgebiete, die ihr da habt, besser geeignet?
Einiges kann man sicherlich weiterhin in Java machen. Aber manchmal kommt Java an seine Grenzen und dann klingelt das Telefon: "Warum dauert das so lange? Warum fehlen diese Funktionen, die ich in allen anderen Win-Programmen habe? Warum...."
Gregor schrieb:
Meinst du, mit C++ kann es nicht vorkommen, dass irgendwo ein Drucker unter SP2 nicht funktioniert? Da glaube ich nicht so ganz dran.
Ja, denn komischerweise kann der User mit allen anderen Programmen auf diesem Drucker drucken. Ja, selbst vor der Java5-Umstellung konnte er mit unserem Programm auf dem Drucker drucken. Erst mit Java5 streikt dieser.
Ich sage nicht, das C++ perfekt ist. Aber alle denken, das es Java ist. Und ich habe im Sommer 2000 meinen ersten Java-Tag gehabt, 2001 gings knall hart los. Wir haben User in Deutschland, England (Bentley), in Tschechien (Skoda), in Spanien (Seat) in Mexiko usw. Und von fast überall gabs schon mal Anrufe oder Mails, das etwas Java-spezifisches nicht funktioniert.
Auf einem Webserver, wo JSP oder Servlets laufen, mag alles i.O. laufen. Weil diese Sachen auf einem speziellen Rechner laufen. Aber sobald komplexere Java-Clients auf vielen PCs, weltweit laufen müssen, ist es aus mit der schönen Java-Welt.
-
Bezahlt Sun einer Firma Geld dafür wenn sie Java benutzt?
-
Achja, noch ne nette Story, die nicht direkt was mit Java zu tun hat. Ich war mal auf einer Cache-Intersystems Tages-Schulung, weil mich OO-Datenbanken sehr begeistern. Im Gespräch mit einem der dt. Intersystems-Manager kam heraus, das diese mehrmals versucht haben Cache bei unserem Kunden rein zubringen. Sogar für die erste Zeit (Jahre?) kostenlos. Denn so ein Mega-Konzern kann sich langfristig auszahlen. VW hat ihnen aber keinen Hauch einer Chance gegeben. Er meinte, die Argumente die für Cache sprechen, waren praktisch nicht von interesse.
Ich kann nur sagen, das ist eine Erfahrung die ich auch gemacht habe.
Und glaubt mir, unser Kunde ist nicht die Ausnahme auf diesem Planeten. Politik (was das in der Wirtschaft heißt, hab ich schon oben gesagt) spielt eine viel größere Rolle.
-