JAVA schneller als C++ ? Stimmt das???

[Gast]

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.

[net 0]

Optimizer schrieb:

Wobei sich der Sinn mir nicht ganz erschließt.

der sinn eines chips, der java bytecode direkt ausführen kann? oder was?

[Gast]

Ja, genau. So war es gemeint.

[aMan]

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.

[Dr. Prof]

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 arbeiten

Java 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..

[Enterprise Architect]

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?

[nep]

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...

[Gregor]

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.

[GPC]

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++

[Artchi]

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?

[groovemaster]

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.

[Gregor]

groovemaster schrieb:

Optimizer schrieb:

Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen.

Quellen?

Bestimmt kommt er gleich wieder mit dem Somasegar-Blog!

@groovemaster: Mein "Blah blah blah" war übertrieben. Das sehe ich ein. Dennoch ist es so, dass die JVM als zwischengeschaltete Maschine in der Praxis kein wirklicher Performancefaktor ist. In der Theorie kannst Du Überlegungen in beide Richtungen anstellen. Da kann man sich gedanklich sowohl Vorteile als auch Nachteile der JVM konstruieren, keine Frage. Wenn die JVM wirklich ein derartiger Performancekiller wäre, wie man es nach deinem Beitrag hätte denken können, könnte man kein Javaprogramm konstruieren, dass bis auf wenige Prozentpunkte an die Ausführungsgeschwindigkeit eines C++ Programms herankommen könnte. Das ist bei einfachen Programmen aber fast immer der Fall. "Interpretation" von Java Bytecode ist ein Begriff, der mit den ganz frühen JVMs verbunden ist. Das war zu Zeiten, als Javaprogramme vielleicht 100 mal langsamer als vergleichbare C++-Programme waren. Deshalb habe ich da so allergisch reagiert. "Interpretation" ist eine Technik, die die heutige Funktionsweise von JVMs nicht mehr passend beschreibt und steht als Wort letztendlich für diesen sehr großen Performancefaktor, den ich da oben erwähnt habe. Der Jitter oder auch der Hotspot-Jitter, wie ihn heutige JVMs haben, ist dazu ein Unterschied wie Tag und Nacht.

[Gast]

groovemaster schrieb:

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.

Ok, wir sind uns einig, betrachten wir das von der theoretischen Seite. Dann erklär jetzt nochmal genau, wie JIT-Compilierung die Performance negativ beeinflusst. Wir sind uns hoffentlich auch einig, dass die JIT-Compilierung gemessen an der Programmlaufzeit ein konstanter Overhead ist. Konstanter Aufwand ist theoretisch völlig bedeutungslos. Da geh' ich zum Litec (Computerladen in München) und kaufe 'nen schnelleren PC und schon ist der Overhead wieder weg. So viel zur Theorie.

Optimizer schrieb:

aber was soll's

Das ist die richtige Einstellung für einen Programmierer.

Klar. Man muss immer wissen, wann was einem egal sein kann.

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...

Die besagt, dass nur 20% des Codes eines Programms für die Performance von Bedeutung sind. Diese 20% sind harte Numbercrunching-Aufgaben wie Raytracing, wenn du einen 3D-Modeller schreibst. Und nicht die 80% des Codes, die das GUI und das Speichern der Benutzereinstellungen, usw. ausmachen. Das steht im Gegensatz zu deiner Ansicht, dass Performance durchgehend im ganzen Programm an jeder Stelle wichtig ist.

Optimizer schrieb:

Nein.

Nein? Aber sicher doch! Ein C++ Compiler _kennt_ die Plattform, für die er kompiliert.

Nein. Er kennt sie nicht gut genug.

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 [...]

Ich habe doch vom Inlining gesprochen. Wie soll ein Compiler/Linker ohne die Implementierung zu kennen, inlinen können?

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.

Der Punkt war: Man fasst in der Regel zusammen, was man kann. Man compiliert nicht für Pentium I, II, III, IV, 4 D (mit x64) mal Windows 9x, NT, Linux, macht insgesamt 15 Compilate ohne AMD. Zeig mir eine ernstgemeinte Software, für die es so viele Compilate gibt. Nein, man macht ne x86 Version, die ist dann schlecht optimiert, weil sie auf die gemeinsame Schnittmenge der Prozessoren aufbauen muss. Da liegen dann viele Möglichkeiten brach.

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?

Wieso nicht? Weil der Compiler vor dem Programmstart ins Spiel kommt. Ist doch ganz klar!

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"?

Beispielsweise ich lade ne DLL hinzu, die kommt an irgendne Basisadresse im Textsegment. Jetzt rufe ich darin ne Funktion auf. Mein Programm wurde jetzt aber schon compiliert, also muss es die Adresse der Funktion ausrechnen, Basisadresse + Funktionsoffset. Bei JIT-linking wüsste ich nach der JIT-compilierung, wo die Funktion der DLL im Speicher steht und kann während der JIT-compilierung meines Codes direkt die Adresse eintragen.

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.

Ähm weiß nicht. Die Portabilität des Bytecodes ist jedenfalls nicht schlechter.

Optimizer schrieb:

Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen.

Quellen?

Ich bin der Anfang (und das Ende). Ich habe es doch begründet. Wie gesagt, wir betrachten des ja von der theoretischen (der einzig sinnvollen) Seite. Der Wirtschaftler sagt natürlich "des Programm war jetzt in C++ geschrieben 5% schneller", ob einfach nur der Compiler besser war, findet er nicht so wichtig. Es gibt eine Menge weitere nicht-Performance Gründe, warum JIT-Compilierung auch einfach viel einfacher ist, im Zusammenhang mit Bibliotheken, die eben nicht nur aus C-Funktionen bestehen, sondern Klassen bereitstellen, von denen man ableiten können soll, usw... es geht alles irgendwie über 20 Indirektionen, aber JIT-Compilerung ist der bessere Weg, weil der Compiler dann sowohl das Hauptprogramm als auch die Lib vor sich liegen hat.

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.

Das Problem ist: Du hast deine Aussage über Langsamkeit explizit mit dem Interpretieren begründet. Wenn du nur beiläufig vom Interpretieren sprichst und das nicht als echter Grund genannt wird, hänge ich mich daran schon nicht auf.

[Gast]

Gregor schrieb:

groovemaster schrieb:

Optimizer schrieb:

Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen.

Quellen?

Bestimmt kommt er gleich wieder mit dem Somasegar-Blog!

Ne, ich find schon noch was anderes geiles.

[nep]

Gregor schrieb:

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.

Moment, ich bin keinesfalls ein SWT-Verfechter oder so Ich habs noch nicht mal wirklich verwendet beim Entwickeln, aber ich durfte mal im selben Raum sitzen mit einem, der damit ein Plugin für Eclipse schreiben musste. Man hat der geflucht
Ich hab das eigentlich eher aus Benutzersicht geschildert und da existiert IMHO schon eine Verbesserung von SWT gegenüber Swing.
Vor allem sollte man bei Swing auch bedenken, dass nicht jeder die neusten High-End PCs hat und da reichen auch schon leichtgewichtigere Swing-Anwendungen um den PC in die Knie zu zwingen, wobei derselbe PC mit MFC/WinAPI locker fertig werden würde.
Prinzipiell finde ich Swing auch ne tolle Sache, vor allem beim Entwickeln. Das ist, wie schon gesagt, äußerst angenehm da ne GUI zusammenzubasteln Aber eben da liegt bei vielen Java-Anwendungen IMHO eben auch das, was sie langsamer macht. Aber vielleicht ändert sich ja wirklich was in Zukunft daran.

[net 0]

net schrieb:

Optimizer schrieb:

Wobei sich der Sinn mir nicht ganz erschließt.

der sinn eines chips, der java bytecode direkt ausführen kann? oder was?

Optimizer schrieb:

Ja, genau. So war es gemeint.

man braucht keine extra stück software (virtual machine) um den code auszuführen. das musste dir ungefähr so vorstellen, als wenn dein ganzes windows einschliesslich aller anwendungen ständig in vmware, swista, virtual pc o.ä. laufen würde. du belastest die hardware zu 100%, bekommst aber nur 60% der rechenleistung. obwohl man sich daran gewöhnen kann ist das ganze verhalten ziemlich träge und programme starten sehr langsam im vergleich zum original. so ein java chip ist z.b. gut für j2me enabled devices, allein schon wegen des geringeren energieverbrauchs...

[rapso]

Optimizer schrieb:

Ok, wir sind uns einig, betrachten wir das von der theoretischen Seite. Dann erklär jetzt nochmal genau, wie JIT-Compilierung die Performance negativ beeinflusst.

nicht der JIT an sich, sondern das ganze system an sich sorgt für schlechte performance, weil das programm erstmal in bytecode und anschliessend in maschinencode (mittels JIT) umgewandelt wird. alle optimierungen die man vom eigentlichen source bis zum microcode sonst "weiß" werden durch erzeugung von temporärem bytecode nirgenswo hinterlegt und sind weg. möchte man durch ein array durchitterieren, ist der schnellste weg bei einer ARM-cpu der tödlichste für eine x86-cpu und umgekehrt sieht es änlich unoptimal aus. das ließt ein compiler natürlich aus dem source und generiert dann microcode der am besten für die cpu ist oder bytecode ins blaue hinaus (und der JIT kann danach nichts tolles mehr machen, weil ihm die informationen fehlen).

um es auf das menschliche dasein zu übertragen: ich erzähle einen witz auf deutsch, eine zweite person schreibt sich alle wörter die dabei auftreten auf und übersetzt sie 1:1 ins englische und du als JIT der vom ursprünglichen witz nichts weiß und nur english kann ließt das. ich hoffe du kannst dir vorstellen wieviel witzinformation am ende in deinem hirn ankommt.

Optimizer schrieb:

Die besagt, dass nur 20% des Codes eines Programms für die Performance von Bedeutung sind. Diese 20% sind harte Numbercrunching-Aufgaben wie Raytracing, wenn du einen 3D-Modeller schreibst. Und nicht die 80% des Codes, die das GUI und das Speichern der Benutzereinstellungen, usw. ausmachen. Das steht im Gegensatz zu deiner Ansicht, dass Performance durchgehend im ganzen Programm an jeder Stelle wichtig ist.

wie auch das moor'sche gesetzt, wird diese regel auch sehr oft total falsch interpretiert.
die 20:80 regel beziehen sich auf code an sich, nicht auf ein ganzes programm. 20% vom code ist performancerelevat. also 20% vom mubercrunching (vielleicht der teil, der dividiert?), 20% der gui(könnte der teil der rendert sein?) und 20% vom code für einen button der gui (könnte auch seine render/paint funktion sein?). dementsprechend kann sowohl das "Numnrcrunchen", GUI oder auch die mousebuttonabfrage sehr viel mehr performance kosten als es sein müßte. (bestes beispiel sind viele java apps mit swing sowie c# apps und deren guilib, die großteile der performance fressen und nicht das "numbercrunching" an sich ).

Optimizer schrieb:

Optimizer schrieb:

Nein.

Nein? Aber sicher doch! Ein C++ Compiler _kennt_ die Plattform, für die er kompiliert.

Nein. Er kennt sie nicht gut genug.

er weiß besser wie er den source über die einzelnen stufen hinweg zu microcode umwandelt als es der javacompiler+JIT wissen können.

Optimizer schrieb:

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.

Der Punkt war: Man fasst in der Regel zusammen, was man kann. Man compiliert nicht für Pentium I, II, III, IV, 4 D (mit x64) mal Windows 9x, NT, Linux, macht insgesamt 15 Compilate ohne AMD. Zeig mir eine ernstgemeinte Software, für die es so viele Compilate gibt.

macht der Intel Compiler automatisch und beim start wird das jeweilige codestück ausgewählt, dass am besten für eine cpu ist. mit einem hack (hat heise irgendwo auch genauer beschrieben), kann man patchen, dass auch das best passendste binary für AMD-cpus genommen wird. nebenbei gibt es diese "BigBinaries" schon länger, hatte z.b. apple bei umstellungen auf neue cpus benutzt und afaik gibt es bei WinCE auch diese vorgehensweise um möglichst viele cpus zu unterstützen. es gibt natürlich auch die möglichkeit binaries im voraus oder zur laufzeit auf neue cpus umzustellen (so wie es in etwa am anfang bei java war bzw mit JIT läuft), wurde/wird z.b. beim itanium gemacht um x86-code auszuführen.

Optimizer schrieb:

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?

Wieso nicht? Weil der Compiler vor dem Programmstart ins Spiel kommt. Ist doch ganz klar!

genau wie java, gibt es auch bei anderen sprachen die möglichkeit den ersten durchlauf mit profilling durchlaufen zu lassen, dann weiß der compiler das und kann im zweiten pass drüber gehen und diese problemstellen wegoptimieren.

Optimizer schrieb:

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"?

Beispielsweise ich lade ne DLL hinzu, die kommt an irgendne Basisadresse im Textsegment. Jetzt rufe ich darin ne Funktion auf. Mein Programm wurde jetzt aber schon compiliert, also muss es die Adresse der Funktion ausrechnen, Basisadresse + Funktionsoffset. Bei JIT-linking wüsste ich nach der JIT-compilierung, wo die Funktion der DLL im Speicher steht und kann während der JIT-compilierung meines Codes direkt die Adresse eintragen.

afaik wird beim laden einer dll beim programmaufruf, jede auf die dll referenzierende stelle im programm mit der richtigen address der funktionen der dll überschrieben, so wie es der jit macht (find ich auch seltsam, aber hab ich auf irgend ner msdn seite gelesen, drum glaub ich das). man hat aber den vorteil, dass nicht in einer virtuellen umgebung diese arbeit durchgeführt wird, sondern im OS, was das mehrmalige laden von modulen erspart.

Optimizer schrieb:

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.

Ähm weiß nicht. Die Portabilität des Bytecodes ist jedenfalls nicht schlechter.

welche sprache außer java generiert denn noch bytecode für den JIT ?

Optimizer schrieb:

Optimizer schrieb:

Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen.

Quellen?

Ich bin der Anfang (und das Ende). Ich habe es doch begründet. Wie gesagt, wir betrachten des ja von der theoretischen (der einzig sinnvollen) Seite. Der Wirtschaftler sagt natürlich "des Programm war jetzt in C++ geschrieben 5% schneller", ob einfach nur der Compiler besser war, findet er nicht so wichtig. Es gibt eine Menge weitere nicht-Performance Gründe, warum JIT-Compilierung auch einfach viel einfacher ist, im Zusammenhang mit Bibliotheken, die eben nicht nur aus C-Funktionen bestehen, sondern Klassen bereitstellen, von denen man ableiten können soll, usw... es geht alles irgendwie über 20 Indirektionen, aber JIT-Compilerung ist der bessere Weg, weil der Compiler dann sowohl das Hauptprogramm als auch die Lib vor sich liegen hat.

es ist aus meiner sicht der schlechtere weg. der c++ compiler hat alle sourcen meistens zur verfügung um daraus das beste binary zu generieren. DLLs und andere module sind meist komplett abgeschlossene bereiche mit schnittstellen, die nicht performancekritisch sind. alles was performancekritisch ist, ist meistens in einem binary für sich und es wurde aus dem source direkt ins binary optimiert. bei java wird meines wissens nach jede klasse zu einem bytecode-objekt und danach erst mit JIT zusammengefasst, an der stelle des byte-objekts ist bei c++ hingegen schon jede optimierung gelaufen und würde selbst mit einem JIT nichts mehr reissen können.

java wurde entwickelt um
1. bei niedrigem programmierniveau sicheren coden zu gewährleisten (kostenersparnis)
2. möglichst extrem flexibel zu sein durch eben modularisierung (kostenersparnis)
3. leicht portierbarkeit "Write once, run everywhere" (mehr potentiellen markt -> größere margen)

java wurde nicht entwickelt um
1. schnell zu sein und ne performancekrone zu erhalten (im gegenteil, wurde anfangs nur mit interpretern ausgeliefert und mußte später JITs erhalten, damit es nicht 10x langsammer läuft als andere sprachen, nachdem MS für j++ soeinen erstellte)
2. um c++ zu ersetzen (im gegenteil, wichtier code soll weiterhin von hoghqualifizierten kräften in c/c++ erstellt werden z.b. SunOS)
3. allround eingesetzt zu werden

deswegen sollte man erst garnicht versuchen java als schneller darzustellen, ist wie ein vergleich eines ferraris mit einem trecker und der versuch mittels der ps-zahl die mögliche endgeschwindigkeit abzuschätzen.

mal ganz ehrlich. wenn man ein "perfektes" programm für sich haben möchte, stellt man nen hochqualifizierten coder ein und lässt es ihn in c++ machen und zahlt entsprechend (weil man etwas gutes haben möchte und für soviel geld dann auch verlangen darf dass es kein speicherfresser ist). wenn man ein "perfektes" programm für den markt haben möchte, weil es irgendjemand benutzen soll der dafür geld ausgibt, dann stellt man sich zwei studenten/praktikanten ein und lässt sie es in java/c# schreiben und spart geld und kann sich sicher sein, dass das programm, egal wie es laufen wird, wohl keine accessviolations werfen wird (weil man $$$ machen möchte)

greets
rapso

[omg omg]

rapso schrieb:

Optimizer schrieb:

Ok, wir sind uns einig, betrachten wir das von der theoretischen Seite. Dann erklär jetzt nochmal genau, wie JIT-Compilierung die Performance negativ beeinflusst.

nicht der JIT an sich, sondern das ganze system an sich sorgt für schlechte performance, weil das programm erstmal in bytecode und anschliessend in maschinencode (mittels JIT) umgewandelt wird. alle optimierungen die man vom eigentlichen source bis zum microcode sonst "weiß" werden durch erzeugung von temporärem bytecode nirgenswo hinterlegt und sind weg. möchte man durch ein array durchitterieren, ist der schnellste weg bei einer ARM-cpu der tödlichste für eine x86-cpu und umgekehrt sieht es änlich unoptimal aus. das ließt ein compiler natürlich aus dem source und generiert dann microcode der am besten für die cpu ist oder bytecode ins blaue hinaus (und der JIT kann danach nichts tolles mehr machen, weil ihm die informationen fehlen).

um es auf das menschliche dasein zu übertragen: ich erzähle einen witz auf deutsch, eine zweite person schreibt sich alle wörter die dabei auftreten auf und übersetzt sie 1:1 ins englische und du als JIT der vom ursprünglichen witz nichts weiß und nur english kann ließt das. ich hoffe du kannst dir vorstellen wieviel witzinformation am ende in deinem hirn ankommt.

Optimizer schrieb:

Die besagt, dass nur 20% des Codes eines Programms für die Performance von Bedeutung sind. Diese 20% sind harte Numbercrunching-Aufgaben wie Raytracing, wenn du einen 3D-Modeller schreibst. Und nicht die 80% des Codes, die das GUI und das Speichern der Benutzereinstellungen, usw. ausmachen. Das steht im Gegensatz zu deiner Ansicht, dass Performance durchgehend im ganzen Programm an jeder Stelle wichtig ist.

wie auch das moor'sche gesetzt, wird diese regel auch sehr oft total falsch interpretiert.
die 20:80 regel beziehen sich auf code an sich, nicht auf ein ganzes programm. 20% vom code ist performancerelevat. also 20% vom mubercrunching (vielleicht der teil, der dividiert?), 20% der gui(könnte der teil der rendert sein?) und 20% vom code für einen button der gui (könnte auch seine render/paint funktion sein?). dementsprechend kann sowohl das "Numnrcrunchen", GUI oder auch die mousebuttonabfrage sehr viel mehr performance kosten als es sein müßte. (bestes beispiel sind viele java apps mit swing sowie c# apps und deren guilib, die großteile der performance fressen und nicht das "numbercrunching" an sich ).

Optimizer schrieb:

Optimizer schrieb:

Nein.

Nein? Aber sicher doch! Ein C++ Compiler _kennt_ die Plattform, für die er kompiliert.

Nein. Er kennt sie nicht gut genug.

er weiß besser wie er den source über die einzelnen stufen hinweg zu microcode umwandelt als es der javacompiler+JIT wissen können.

Optimizer schrieb:

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.

Der Punkt war: Man fasst in der Regel zusammen, was man kann. Man compiliert nicht für Pentium I, II, III, IV, 4 D (mit x64) mal Windows 9x, NT, Linux, macht insgesamt 15 Compilate ohne AMD. Zeig mir eine ernstgemeinte Software, für die es so viele Compilate gibt.

macht der Intel Compiler automatisch und beim start wird das jeweilige codestück ausgewählt, dass am besten für eine cpu ist. mit einem hack (hat heise irgendwo auch genauer beschrieben), kann man patchen, dass auch das best passendste binary für AMD-cpus genommen wird. nebenbei gibt es diese "BigBinaries" schon länger, hatte z.b. apple bei umstellungen auf neue cpus benutzt und afaik gibt es bei WinCE auch diese vorgehensweise um möglichst viele cpus zu unterstützen. es gibt natürlich auch die möglichkeit binaries im voraus oder zur laufzeit auf neue cpus umzustellen (so wie es in etwa am anfang bei java war bzw mit JIT läuft), wurde/wird z.b. beim itanium gemacht um x86-code auszuführen.

Optimizer schrieb:

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?

Wieso nicht? Weil der Compiler vor dem Programmstart ins Spiel kommt. Ist doch ganz klar!

genau wie java, gibt es auch bei anderen sprachen die möglichkeit den ersten durchlauf mit profilling durchlaufen zu lassen, dann weiß der compiler das und kann im zweiten pass drüber gehen und diese problemstellen wegoptimieren.

Optimizer schrieb:

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"?

Beispielsweise ich lade ne DLL hinzu, die kommt an irgendne Basisadresse im Textsegment. Jetzt rufe ich darin ne Funktion auf. Mein Programm wurde jetzt aber schon compiliert, also muss es die Adresse der Funktion ausrechnen, Basisadresse + Funktionsoffset. Bei JIT-linking wüsste ich nach der JIT-compilierung, wo die Funktion der DLL im Speicher steht und kann während der JIT-compilierung meines Codes direkt die Adresse eintragen.

afaik wird beim laden einer dll beim programmaufruf, jede auf die dll referenzierende stelle im programm mit der richtigen address der funktionen der dll überschrieben, so wie es der jit macht (find ich auch seltsam, aber hab ich auf irgend ner msdn seite gelesen, drum glaub ich das). man hat aber den vorteil, dass nicht in einer virtuellen umgebung diese arbeit durchgeführt wird, sondern im OS, was das mehrmalige laden von modulen erspart.

Optimizer schrieb:

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.

Ähm weiß nicht. Die Portabilität des Bytecodes ist jedenfalls nicht schlechter.

welche sprache außer java generiert denn noch bytecode für den JIT ?

Optimizer schrieb:

Optimizer schrieb:

Das Konzept der JIT-Compilierung ist insgesamt völlig überlegen.

Quellen?

Ich bin der Anfang (und das Ende). Ich habe es doch begründet. Wie gesagt, wir betrachten des ja von der theoretischen (der einzig sinnvollen) Seite. Der Wirtschaftler sagt natürlich "des Programm war jetzt in C++ geschrieben 5% schneller", ob einfach nur der Compiler besser war, findet er nicht so wichtig. Es gibt eine Menge weitere nicht-Performance Gründe, warum JIT-Compilierung auch einfach viel einfacher ist, im Zusammenhang mit Bibliotheken, die eben nicht nur aus C-Funktionen bestehen, sondern Klassen bereitstellen, von denen man ableiten können soll, usw... es geht alles irgendwie über 20 Indirektionen, aber JIT-Compilerung ist der bessere Weg, weil der Compiler dann sowohl das Hauptprogramm als auch die Lib vor sich liegen hat.

es ist aus meiner sicht der schlechtere weg. der c++ compiler hat alle sourcen meistens zur verfügung um daraus das beste binary zu generieren. DLLs und andere module sind meist komplett abgeschlossene bereiche mit schnittstellen, die nicht performancekritisch sind. alles was performancekritisch ist, ist meistens in einem binary für sich und es wurde aus dem source direkt ins binary optimiert. bei java wird meines wissens nach jede klasse zu einem bytecode-objekt und danach erst mit JIT zusammengefasst, an der stelle des byte-objekts ist bei c++ hingegen schon jede optimierung gelaufen und würde selbst mit einem JIT nichts mehr reissen können.

java wurde entwickelt um
1. bei niedrigem programmierniveau sicheren coden zu gewährleisten (kostenersparnis)
2. möglichst extrem flexibel zu sein durch eben modularisierung (kostenersparnis)
3. leicht portierbarkeit "Write once, run everywhere" (mehr potentiellen markt -> größere margen)

java wurde nicht entwickelt um
1. schnell zu sein und ne performancekrone zu erhalten (im gegenteil, wurde anfangs nur mit interpretern ausgeliefert und mußte später JITs erhalten, damit es nicht 10x langsammer läuft als andere sprachen, nachdem MS für j++ soeinen erstellte)
2. um c++ zu ersetzen (im gegenteil, wichtier code soll weiterhin von hoghqualifizierten kräften in c/c++ erstellt werden z.b. SunOS)
3. allround eingesetzt zu werden

deswegen sollte man erst garnicht versuchen java als schneller darzustellen, ist wie ein vergleich eines ferraris mit einem trecker und der versuch mittels der ps-zahl die mögliche endgeschwindigkeit abzuschätzen.

mal ganz ehrlich. wenn man ein "perfektes" programm für sich haben möchte, stellt man nen hochqualifizierten coder ein und lässt es ihn in c++ machen und zahlt entsprechend (weil man etwas gutes haben möchte und für soviel geld dann auch verlangen darf dass es kein speicherfresser ist). wenn man ein "perfektes" programm für den markt haben möchte, weil es irgendjemand benutzen soll der dafür geld ausgibt, dann stellt man sich zwei studenten/praktikanten ein und lässt sie es in java/c# schreiben und spart geld und kann sich sicher sein, dass das programm, egal wie es laufen wird, wohl keine accessviolations werfen wird (weil man $$$ machen möchte)

greets
rapso

troll

[frenki]

Java ist für die die einfach schnell und einfach entwickeln wollen und denen die User egal sind.

Das zeigt doch die Diskussion Swing vs. SWT in diesem Thread. Ein Programmierer der solche Entscheidungen aus Sicht der Entwicklung und nicht aus Sicht des Anwenders trifft hat in meinen Augen sowieso den Beruf verfehlt. Für die ist Java genau richtig.

[Gast]

Ja, JAVA ist schneller...schneller im Resourcen verschlucken... *grins