JAVA schneller als C++ ? Stimmt das???
-
Also hier an der Uni arbeietet Lehrstuhl 4 (www4.informatik.uni-erlangen.de) an einem Betriebsystem welches in Java geschrieben ist. http://www.jxos.org/
Die VM und der Compiler wurde selbst geschrieben.
Laut Aussage derer steckt im JavaBytecode so viel Wissen drin, dass man dadurch richtig gut optimiren kann.
Also deren (teilsweise) JustInTime-Compiler macht aus JavaByteCode gleich schnellen Assembler.Die nutzen also die guten Teile von Java und bringen es schnell auf die Maschine runter.
Also z.B. wird aus einer in Java geschriebenen MemoryMapMethode ein paar Brocken Assembler.Und durch die teilsweise extremen Optimierungen sind die - laut Aussage - manchmal auch schneller als C++.
-
@Gregor: Sehr guter Beitrag. Hast Du vielleicht auch noch Links bezüglich des JIT compilings? Also wie genau das funktioniert, denn schließlich muss ja der Maschinencode auch noch an die CPU weitergereicht werden? Werden komplette Methoden nativ übersetzt? Bei Sun konnte ich nur allgemeines zu diesem Thema finden.
-
@gregor schrieb:
Hast Du vielleicht auch noch Links bezüglich des JIT compilings?
Es gibt bei Sun ne ganze Menge zu deren "Hotspot-JVM":
http://java.sun.com/products/hotspot/
Ist sicherlich nicht in komprimierter Form das, was dich interessiert, aber da sollte trotzdem ne ganze Menge drinstehen, was Dich interessiert.
-
Gregor schrieb:
Blah blah blah!
Wieviel so ein paar nichtssagende Worte letztendlich doch sagen...
Gregor schrieb:
Es ist deshalb eine Verzerrung der Tatsachen, weil die JVM den Bytecode zur Laufzeit kompiliert.
Ach, und das kostet keine Zeit? Kannst du mir verraten, was für einen Rechner du hast? So einen möchte ich nämlich auch gerne haben.
Gregor schrieb:
Und da Du Performance meistens da brauchst, wo Du viel verarbeiten musst, kann dieser Aspekt eigentlich vernachlässigt werden.
Nein, ich habe von der kompletten Anwendung gesprochen. Und nicht nur von einzelnen Sequenzen.
Gregor schrieb:
Zudem können - wenn Du so prinzipielle Erwägungen machst - bei einer Kompilation zur Laufzeit bessere Optimierungen vorgenommen werden. Hier ist zum einen die genaue darunterliegende Plattform bekannt
Das ist bei einer Kompilation von C++ Programmen auch der Fall.
Gregor schrieb:
zum anderen ist aber auch der Zustand des Programms bekannt. Beide Aspekte könnten - vom Prinzip her
In einem gewissen statischen Rahmen ist C++ Compilern der Zustand des Programmes auch bekannt. Und "könnten" oder "vom Prinzip her" ist für mich keine logische Erklärung, wieso das zur Laufzeit vorteilhafter sein soll.
Zu 2. kann ich ehrlich gesagt nichts sagen, weil ich nicht weiss, worauf du dich beziehst. Aber bei Performancefragen über Generizität zu sprechen, ist leicht verfehlt. Mit Templates gewinnst du ja auch in C++ keine Performance. Dazu sind sie auch nicht da. Klar, sagt jetzt jemand, mit Template Meta Programmierung kann ich Sachen zur Kompilierungszeit schon berechnen und spar mir damit Laufzeit. Damit hat er natürlich Recht. Das ist aber nur eine spezielle Nutzung von Templates und für Java sowieso uninteressant, da, soweit ich weiss, Java nur Laufzeitgenerizität bietet.
Versteh mich nicht falsch, ich habe nicht geschrieben, dass C++ schnell ist und Java langsam. Auf dem Papier ist es aber erstmal so, dass mit Kompilersprachen schnellere Programme möglich sind als mit Interpretersprachen. Das ist Fakt, und liegt ganz einfach in der technischen Tatsache begründet, dass der "interpretierte" Code zur Laufzeit noch für die entsprechende Plattform verarbeitet werden muss. So die Theorie. Dass die Praxis aber ganz anders aussehen kann, wissen wir ja nun mittlerweile. Und bei einer aktuellen JVM sieht man, dass durch Optimierungen und gute Strategien Anwendungen mit absolut akzeptabler Geschwindigkeit laufen. Letztendlich hat das aber weniger mit der Sprache ansich zu tun, als vielmehr mit der Implementierung. Deshalb stören mich auch Sätze wie
Und durch die teilsweise extremen Optimierungen sind die - laut Aussage - manchmal auch schneller als C++.
Man kann die Geschwindigkeit von C++ nicht messen! Was man messen kann, sind Implementierungen. Deswegen aber Rückschlüsse auf _alle_ Implementierungen zu ziehen, ist schlichtweg Blödsinn.
-
Man kann es leider nicht oft genug sagen, da es manche immer noch nicht verstanden haben:
1.) Java ist für größere Client-Systeme(fat-clients) erheblich langsamer, was aber besonders durch den enormen Speicherverbrauch kommt(Hauptursache: Swing).
2.) Java ist die mit Abstand beste Sprache für Enterprise Lösungen. Dort kommen auch die von Gregor genannten Optimierungen ins Spiel. Klar ist der Programmstart und die ersten Abläufe durch das JIT langsamer, aber welche Rolle spielt das auf einem System was meistens ne Uptime von Monaten hat?
3.) Es gibt im Enterprise Bereich zu Java keine ernstzunehmende Konkurrenz. Das selbe gilt für browserbasierte Clients. Java hat für solche Systeme sehr gute Eigenschaften.
4.) Fakt bleibt weiterhin: Ein gleiches System wäre in C++ sicherlich minimal performanter(allein schon durch die vielen Speicherzugriffe von Java), aber welche Rolle spielt das in Zeiten wo ein Dual-Opteron System mit 4GB RAM keine 3.000 Euro mehr kostet? Dieser Preis ist für ein Unternehmen das solche Systeme betreibt ein Witz. Davon stellt man sich gerne 3 Stück hin. Was spielen da noch 5-10% Performance Einbußen für eine Rolle?
5.) Die Diskussion ist verallgemeinert einfach schwachsinn. Man kann nur ein genaues Einsatzgebiet vergleichen. In der professionellen Softwareentwickleung spielen viele andere Kriterien eine Rolle. 5-10% Performanceeinbußen gehören äussert selten dazu.
Alles andere ist wie Gregor schon sagte: "bla bla"6.) Für Mainframes gibt es schon längst Co-Prozessoren die Java Bytecode nativ verstehen. Das unterstreicht wohl die Bedeutsamkeit von Java in riesigen Systemen!
-
Hi,
in diesem Zusammenhang sicherlich auch sehr interessant ist das Low Level Virtual Machine-Projekt (http://llvm.org/).
Damit kann- Währen der Compile-Time
- Während der Link-Time
- Während der Laufzeit
optimiert werden.
Damit könnte man evt. ziemlich gut messen, was eine virtuelle Maschine wirklich bringt.mfg,
pcmoritz.
-
Was meinste mit Enterprise?
-
Enterprise Architect schrieb:
6.) Für Mainframes gibt es schon längst Co-Prozessoren die Java Bytecode nativ verstehen. Das unterstreicht wohl die Bedeutsamkeit von Java in riesigen Systemen!
nicht nur für mainframes: http://www.ajile.com/products/aj100.htm
-
groovemaster schrieb:
Gregor schrieb:
Es ist deshalb eine Verzerrung der Tatsachen, weil die JVM den Bytecode zur Laufzeit kompiliert.
Ach, und das kostet keine Zeit? Kannst du mir verraten, was für einen Rechner du hast? So einen möchte ich nämlich auch gerne haben.
Die JIT-Compilierung ist doch einmalig. Wie soll sich das deiner Meinung nach negativ auswirken? Natürlich dauert der Programmstart u.U. länger, aber was soll's.
Gregor schrieb:
Und da Du Performance meistens da brauchst, wo Du viel verarbeiten musst, kann dieser Aspekt eigentlich vernachlässigt werden.
Nein, ich habe von der kompletten Anwendung gesprochen. Und nicht nur von einzelnen Sequenzen.
Du kennst aber die 80-20 Regel, oder?
Gregor schrieb:
Zudem können - wenn Du so prinzipielle Erwägungen machst - bei einer Kompilation zur Laufzeit bessere Optimierungen vorgenommen werden. Hier ist zum einen die genaue darunterliegende Plattform bekannt
Das ist bei einer Kompilation von C++ Programmen auch der Fall.
Nein.
Ein C++ Compiler kennt zur Compilier-Zeit nicht die dynamisch hinzugelinkten Bibliotheken -> Inlining adé!
Man compiliert auch nie 20 verschiedene Versionen für 20 Prozessoren (ich habe das noch nie gesehen). Stattdessen fasst man fast alle x86-Prozessoren in einem Build zusammen -> neue 32 Bit Register beim AMD64 adé, spezielle Berücksichtigung der weiteren Unterschiede adé.
Es gibt Variablen, die beim Programmstart nur einmal ausgelesen werden und sich amsonsten nicht mehr ändern. Ein C++ Compiler kann dies nicht nutzen.
Ein JIT-Compiler kann auch viel öfters feste Speicheradressen bilden, für die ein statische Compiler eine Indirektion einbauen muss. Das betrifft insbesondere die Fälle, wo man dynamisch was hinzulinkt.Ich schreibe immer "JIT-Compiler", der eigentliche Punkt ist aber auch, dass sämtliches Linking zur Laufzeit stattfindet. Das bringt erhebliche Vorteile beim hinzufügen von Laufzeit-Bibliotheken. Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen. Es gibt genug theoretische Gründe, warum Java-Programme eigentlich schneller laufen müssten. Aber wie du schon festgestellt hast:
Was man messen kann, sind Implementierungen.
Wieviel so ein paar nichtssagende Worte letztendlich doch sagen...
Das kommt davon, wenn man Märchen mit Interpretieren des Bytecodes erzählt. Das ist seit ~10 Jahren schon nicht mehr Stand der Technik.
-
net schrieb:
Enterprise Architect schrieb:
6.) Für Mainframes gibt es schon längst Co-Prozessoren die Java Bytecode nativ verstehen. Das unterstreicht wohl die Bedeutsamkeit von Java in riesigen Systemen!
nicht nur für mainframes: http://www.ajile.com/products/aj100.htm
Wobei sich der Sinn mir nicht ganz erschließt.
-
Optimizer schrieb:
Wobei sich der Sinn mir nicht ganz erschließt.
der sinn eines chips, der java bytecode direkt ausführen kann? oder was?
-
Ja, genau. So war es gemeint.
-
dann laeuft es in akzeptabler zeit..
@topic
kann sein, dass java fuer server und mainframe was bringt, aber auf dem desktop ist es me gaga. ja, kann sein, alles haengt von der implementation ab, dann ist aber die implementation von java gaga. schon eine einfache ide (in diesem fall netbeans) hat eine grottenschlechte performance. und mein 1.73 ghz pentium m ist nicht der langsamste, 1gb ram muessten normalerweise auch ausreichen..aber das ist meine meinung. ich werd hier sicher nicht auf kritiken antworten, ist mir wurscht, wenn ich niedergemacht werde..
mfg aman.
-
Java-Anwendungen fallen im Regel in zwei Kategorien:
a)verwendet swing und man hat das gefühl es ist alles sau lahm
b)verwendet kein swing sondern eine native gui(-lib) und es ist angenehm damit zu arbeitenJava kann ja nix dafür wenn ne Bibliothek langsam ist, wenn ich jetzt ne GUI-Lib in C++ schreibe die 10x langsamer wie swing ist heißt es ja auch nicht, dass c++ anwendungen lahm sind..
-
aMan schrieb:
schon eine einfache ide (in diesem fall netbeans) hat eine grottenschlechte performance. und mein 1.73 ghz pentium m ist nicht der langsamste, 1gb ram muessten normalerweise auch ausreichen..
Eine IDE wie NetBeans ist wohl alles andere als eine durchschnittliche Desktop Anwendung. Und wie schon gesagt, Java ist auf dem Desktop erheblich langsamer, aber dazu muss man den Aufbau und die Probleme von Swing verstehen. Das alles ändert nichts daran das Java sich in der Industrie immer stärker durchsetzt. Gregor hat sicherlich wieder ein paar Jobstatistiken parat?
-
Also da bin ich ein und derselben Meinung. Das was (Desktop)Java-Anwendungen oft so langsam macht ist Swing und nicht Java für sich. Wird z.B. sowas wie SWT benutzt, dann fühlt sich das doch gleich wieder schneller an und v.a. bekommt man auch den schönen Windows Look&Feel. Deshalb kann ich auch Leute nicht verstehen, die z.B. rechenintensiven Code in C++ schreiben wollen und dafür eine GUI mit Java/Swing realisieren wollen. Totaler Schwachsinn.
Nichts desto Trotz wird eine gleiche C++-Anwendung von der gefühlten Geschwindigkeit bestimmt ein bisschen schneller sein (bei gleich "performanten" Implementierungen). Deshalb würde ich auf solche Benchmarks nicht allzu viel geben... Kann gar nicht verstehen wie man sich so darüber aufregen kann. Java wird in der Praxis generell bestimmt nicht schneller als C++ sein, aber trotzdem nahezu gleich performant. Alles andere hängt dann auch vom jeweiligen Einsatzgebiet ab...
-
nep schrieb:
Also da bin ich ein und derselben Meinung. Das was (Desktop)Java-Anwendungen oft so langsam macht ist Swing und nicht Java für sich. Wird z.B. sowas wie SWT benutzt, dann fühlt sich das doch gleich wieder schneller an und v.a. bekommt man auch den schönen Windows Look&Feel.
Hmmm... ich bin eigentlich relativ stark gegen SWT eingestellt. Es mag schon sein, dass SWT ein bischen Performance bringt und es mag auch sein, dass sich eine SWT-GUI "nativer" anfühlt. Aber irgendwie bin ich der Meinung, dass es das nicht wert ist. Ich musste mal etwas mit SWT arbeiten und habe da den Eindruck erhalten, dass die Bedienung von SWT zum k***** ist. ...für den Entwickler meine ich. Zudem muss man sich bei SWT um Dinge kümmern, die Java-untypisch sind. Resourcenmanagement usw.. Und als Sahnehäubchen kommt dann auch noch, dass man seine Software für jede Plattform getrennt anbieten muss und die jeweils passende SWT-Version dazupacken muss. Das alles führt bei mir zu dem Eindruck, dass SWT nicht wirklich zu Java passt.
Da bin ich dann eher für Swing, auch wenn das vielleicht ein paar Nachteile bei der Performance und dem L&F bietet. Ich weiß, dass Sun da stetig dran arbeitet und ich bin da wohl auch relativ geduldig mit Sun. ...zumal mir da noch nie ein echtes Problem aufgefallen ist, das Swing für mich unbenutzbar machen würde.
Hier mal ein Link zu den Desktop-Verbesserungen in der nächsten Javaversion:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/index.html
Da sind, wie man sieht, ne ganze Menge Performance-Verbesserungen, L&F-Verbesserungen und auch Integrationsverbesserungen enthalten, die Swing betreffen.
Die Nachteile gegenüber SWT schwinden also dahin. Und insofern denke ich auch, dass SWT letztendlich nur eine relativ kurz andauernde Modeerscheinung ist. SWT hat auf Dauer keine Existenzberechtigung. ...IMHO.
Gregor hat sicherlich wieder ein paar Jobstatistiken parat?
Sicher, aber ich glaube, die sind hier inzwischen schon allgemein bekannt. Deshalb lass ich das mal. Aber den Jobstatistiken kann man eigentlich nicht entnehmen, dass die Nutzung von Java zunimmt. Man kann Ihnen nur entnehmen, dass die Nutzung von Java über die Zeit relativ gleichbleibend stark ist. ...wobei es natürlich immer wieder irgendwelche Schwankungen nach oben oder nach unten gibt.
-
Also wg. Swing vs. SWT:
Swing ist imho so schön zu programmieren, es tut schon fast weh (da kommt imho kein anderes GUI Framework mit). Es ist schlüssig und sauber aufgebaut, dazu einfach zu handeln und wenn doch mal was komplexeres anfällt, steht es auch stramm auf der Matte. Als es in Java 1.3 zum Ersten Mal dabei war, puh, war das lahm. Da konnte man sich echt noch nen Kaffee holen gehen. Aber inzwischen ist ja stark an der Performanceschraube gedreht worden und das merkt man deutlich. Die nächste Version wird sicher wieder etwas zulegen. Das L&F (also das aktuelle, Aqua) finde ich übrigens sehr ästhetisch, es ist neutral und doch stylisch, imho.
Mit SWT hingegen kann ich schon aus dem Grund nichts anfangen, weil ich dann doch mehrere "Versionen" von meinem Java-Programm machen muss. Das ist irgendwie banane. Außerdem ist das Handling, wie Gregor schon sagte, wirklich öde.
Ich wünschte, es gäbe Swing für C++
-
GPC schrieb:
Ich wünschte, es gäbe Swing für C++
Bin ja leider nie dazu gekommen gtkmm zu nutzen, aber wenn ich mir so die Doku dazu anschaue, würde ich pers. erstmal sagen: gtkmm ist für c++ das, was swing für Java ist. Bezogen auf das Design! Performance jetzt völlig außen vor.
Oder ist gtkmm doch nicht so schön?
-
Optimizer schrieb:
Die JIT-Compilierung ist doch einmalig.
Das spielt doch erstmal gar keine Rolle. Ich habe ja bereits geschrieben, dass ein Vergleich in der Praxis relativ sinnlos ist. Deshalb ist die einzige Möglichkeit, wenn man die Frage überhaupt objektiv beantworten möchte, das ganze von der theoretischen Seite zu betrachten. Dass das im Endeffekt genauso sinnlos ist, sollte wohl klar sein. Und in der Theorie gehört der Programmstart nunmal genauso zur Gesamtlaufzeit, wie der Rest des Programms. Dass das Übersetzen des Bytecodes nur einmalig passiert und damit praktisch keine Auswirkungen auf die Laufzeit des Rumpfprogrammes hat, braucht man auch nicht zu diskutieren. Das war aber auch nicht die Frage.
Optimizer schrieb:
aber was soll's
Das ist die richtige Einstellung für einen Programmierer.
Optimizer schrieb:
Du kennst aber die 80-20 Regel, oder?
Wenn ich davon schon mal was gehört haben sollte, dann isses mir auf jeden Fall entfallen. Erklär mal...
Optimizer schrieb:
Nein.
Nein? Aber sicher doch! Ein C++ Compiler _kennt_ die Plattform, für die er kompiliert.
Optimizer schrieb:
Ein C++ Compiler kennt zur Compilier-Zeit nicht die dynamisch hinzugelinkten Bibliotheken -> Inlining adé!
Natürlich kennt er die Bibliotheken. Er kennt nur die Implementation der Funktionen/Daten/was_auch_immer nicht. Das ist aber auch vollkommen uninteressant, sofern die Bibliothek im richtigen Format, und damit auch implizit für die richtige Plattform vorliegt. Und das weiss der Compiler, wobei es richtigerweise Linker heissen muss, sehr wohl.
Optimizer schrieb:
Man compiliert auch nie 20 verschiedene Versionen für 20 Prozessoren (ich habe das noch nie gesehen). Stattdessen fasst man fast alle x86-Prozessoren in einem Build zusammen
Wer redet denn von Prozessoren? Die Rede war von Plattformen, und da ist der Prozessor nur ein Teil. Du kannst in einem Windows und Linux System den gleichen Prozessor haben, trotzdem brauchst du zwei Kompilate. Selbst für ein und dieselbe Plattform habe ich schon unterschiedliche Kompilate gesehen, zB wenn eine Anwendung eine Basic Binary und eine Binary mit Support für diverse CPU Befehlssatzerweiterungen anbietet. Aber das ist schon wieder zu sehr OT. Fakt ist, ein C++ Compiler und die damit beiliegende Runtime kennen die Plattform. Wäre ja auch sonst zu blöd, wenn die CPU den Maschinencode gar nicht "verstehen" oder das BS die Executable gar nicht laden könnte.
Optimizer schrieb:
Es gibt Variablen, die beim Programmstart nur einmal ausgelesen werden und sich amsonsten nicht mehr ändern. Ein C++ Compiler kann dies nicht nutzen.
Wieso nicht? Und selbst wenn, was wäre dabei der Nachteil?
Optimizer schrieb:
Ein JIT-Compiler kann auch viel öfters feste Speicheradressen bilden, für die ein statische Compiler eine Indirektion einbauen muss. Das betrifft insbesondere die Fälle, wo man dynamisch was hinzulinkt.
Was verstehst du denn unter "festen Speicheradressen"?
Optimizer schrieb:
Ich schreibe immer "JIT-Compiler", der eigentliche Punkt ist aber auch, dass sämtliches Linking zur Laufzeit stattfindet. Das bringt erhebliche Vorteile beim hinzufügen von Laufzeit-Bibliotheken.
Da möchte ich dir ja auch gar nicht widersprechen, zumindest was Codeoptimierung betrifft. Aber wie sieht es zB mit Portabilität aus? C Bibliothen kann man zB auch problemlos mit diversen anderen Sprachen nutzen.
Optimizer schrieb:
Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen.
Quellen?
Optimizer schrieb:
Das kommt davon, wenn man Märchen mit Interpretieren des Bytecodes erzählt. Das ist seit ~10 Jahren schon nicht mehr Stand der Technik.
Ich habe von "interpretieren" gesprochen, weil ich halt in einer Zeit zum ersten mal mit solchen Sprachen in Berührung gekommen bin, als BASIC noch aktuell war. Und das Prinzip ist ja immer noch das gleiche, auch wenn die Technik sich seitdem stark weiterentwickelt hat. Und da ich dachte, dass hier im Forum ein gewisser intellektueller Standard vorherrscht, und ich das nicht extra erwähnen muss, habe ich nicht bewusst dein JIT Buzzword benutzt. Aber für solche "Goldwagenleger" wie dich, werde ich das in Zukunft überdenken.