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

[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

[C++_Programmierer]

frenki schrieb:

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.

Hallo,

Und aus diesem Grund werden wir auch weiterhin bei den ausgereiften
HighEnd-Produkten des bewährten Weltmarktführers bleiben, mit denen
wir in den vergangenen Jahren hervorragende Erfahrungen gemacht
haben.

Die kosten zwar ein bisschen mehr, überzeugen aber durch einen
schnellen Return on Investment durch vorbildliche Sicherheit,
Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit,
und Kontinuität in der Produktpolitik.

Und das ist es schliesslich, worauf es Experten wie meinen
hochqualifizierten Mitarbeitern und mir im harten Tagesgeschäft des
internationalen Wettbewerbs ankommt.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert
durch weltfremde Langzeitstudenten mit Taxischein, hat keinerlei
Chance, will man sich tagtäglich aufs Neue den Herausforderungen der
Globalisierung erfolgreich stellen. Da können einfach nur Lösungen
von Profis für Profis zum Einsatz kommen, die hervorragend durch das
Portfolio der Redmonder Software-Spezialisten abgedeckt werden.

[Achtung]

Die Vervielfältigung der auf den Seiten www.c-plusplus.net, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt (vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden. Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.

[@spasti]

C++_Programmierer schrieb:

frenki schrieb:

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.

Hallo,

Und aus diesem Grund werden wir auch weiterhin bei den ausgereiften
HighEnd-Produkten des bewährten Weltmarktführers bleiben, mit denen
wir in den vergangenen Jahren hervorragende Erfahrungen gemacht
haben.

Die kosten zwar ein bisschen mehr, überzeugen aber durch einen
schnellen Return on Investment durch vorbildliche Sicherheit,
Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit,
und Kontinuität in der Produktpolitik.

Und das ist es schliesslich, worauf es Experten wie meinen
hochqualifizierten Mitarbeitern und mir im harten Tagesgeschäft des
internationalen Wettbewerbs ankommt.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert
durch weltfremde Langzeitstudenten mit Taxischein, hat keinerlei
Chance, will man sich tagtäglich aufs Neue den Herausforderungen der
Globalisierung erfolgreich stellen. Da können einfach nur Lösungen
von Profis für Profis zum Einsatz kommen, die hervorragend durch das
Portfolio der Redmonder Software-Spezialisten abgedeckt werden.

wo hast du denn diesen dünnschiss rauskopiert?

[GPC]

Artchi schrieb:

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.

Doch so ist es auch größtenteils. gtkmm hat imho das beste Design der C++ GUI-Libs, auch QT kann da nicht mithalten. Es ist inzwischen auch sehr flott geworden und schon an gtk+ dran. Auch (und speziell da) auf Windows hat es enorm an Geschwindigkeit hinzugewonnen, etwa seit der 2.6.x Version. Jawohl, gtkmm ist mein Favorit, wenn es um C++ mit GUI geht, da es zudem auch noch plattformunabhängig ist.

Ok, also was stört mich an gtkmm?

1. Die Windows-Portierung ist nach wie vor nicht von jedem zu machen, auch wenn es deutlich besser wird.
2. Das Listen-Widget ist einfach der Horror! Ich schreibe gerade an einem Tool, mit ca. 6 Listen, zwei mit mehreren Spalten und der Rest ist nur einspaltig. Mit Swing hätte ich die einspaltigen Listen kurz über das normale ListModel gelöst (welches hierfür schlicht ausreicht) und für die 2 komplexeren hätte ich halt kur ne eigene Klasse geschrieben. In gtkmm musste ich aber insgesamt drei Klassen schreiben, um nur die Darstellung zu haben. Wie ich die Daten dieses mal parallel zur Darstellung organisiere, weiß ich immer noch nicht. In Swing schmeiße ich die Daten einfach in das ListModel rein, übergebe es der JList und gut ist, es ist einfach besser organisiert.
Und irgendwie brauchte bisher jedes meiner gtkmm Programme irgendwo ne Liste und ich kann mir ums Verrecken nicht merken, wie ich damit umgehen muss, weil das Handling einfach Scheiße ist.

Das war's eigentlich auch schon. Die Pluspunkte überzeugen:
+ Sauberes Design (OOP, namespaces...)
+ Plattformunabhängig
+ Gute Performance
+ Viele Möglichkeiten, da umfangreiche Widgets
+ Die sigc++ und glibmm als Unterbau
- Scheiß krüpplige Liste
- Auf Windows noch etwas schwierig

AFAIK gibt's vom XFCE Projekt auch einen gtk+ Wrapper, der ähnlich wie gtkmm aufgebaut ist, aber der ist halt Linux-only.

Oder ist gtkmm doch nicht so schön?

Doch, ist es

frenki schrieb:

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

Autsch.

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.

Das ist jetzt irgendwie Blödsinn, denn ich will ja auch etwas Spaß am Programmieren haben und nicht den ganzen Tag fluchen, weil mein GUI-Toolkit Müll ist. Ich kenne keine Zahlen, aber schätzungsweise ist es den meistens Usern im Büroalltag wurscht, ob sie da SWT oder Swing vor sich haben (sofern sie überhaupt den Unterschied kennen und wissen, was das ist). Denen ist auch egal, dass ihre Anwendung momentan durch Swing noch etwas lahmer ist. Jedenfalls ist es mir als Büroanwender egal.
Vllt. freuen sie sich aber auch, dass ihre Programme in Swing sind, wenn es dann schneller als SWT ist und IBM den SWT Support einstellt?

MfG

GPC

[Gregor]

rapso schrieb:

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

Was erwartest Du denn da? Keine? Da ist ne Liste mit über 200 entsprechenden Sprachen und Sprachvarianten: http://www.robert-tolksdorf.de/vmlanguages.html

rapso schrieb:

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)

Naja, wer will schon ein "perfektes Programm" haben? ...und welches Programm ist schon perfekt, egal in welcher Sprache es geschrieben ist? In der Wirtschaft gibt es immer Grenzen bezüglich des Budgets, der Zeit usw.. Niemand ist da bereit, für etwas perfektes zu zahlen. Es ist nur eine Frage der Prioritäten. Und man sollte auch nicht vergessen: Wenn man für ein gegebenes Projekt eine feste Zeit zur Verfügung hat und dieses Projekt mit Java schneller entwickeln könnte, bleibt einem mit Java auch mehr Zeit zum Debuggen und zur Optimierung.

Abgesehen davon stellst Du es so dar, als ob man für Java nur unqualifiziertes Personal nehmen würde, für C++ aber die höchstausgebildeten Leute. Hier möchte ich doch nochmal auf die üblichen Jobstatistiken verweisen. Da stehen nämlich auch immer die durchschnittlich gezahlten Gehälter dabei. Und die sind in vergleichbaren Regionen. IMHO gibt es bei Java-Jobs sogar etwas mehr zu verdienen, als bei C++. In jedem Fall ist daraus nicht zu erkennen, dass Java vor allem in Verbindung mit Studentenjobs genutzt wird.

[Gast]

rapso schrieb:

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

Und welche Informationen fehlen da deiner Meinung nach? Es wird ja oft genug kritisiert, dass man aus dem Bytecode wieder den Source herstellen kann. Ein JIT kann (und zwar bereits in der Praxis) Indexprüfungen eliminieren, wenn der Zugriff auf Arrayelemente vorhersehbar ist, er erkennt also beispielsweise for( int i; i < array.length; ++i ); Warum sollte er jetzt nicht für den Prozessor geeigneten Code generieren können?

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.

Dabei gehst du davon aus, dass wegen des Bytecodes Informationsverlust auftritt. Daran glaube ich noch nicht und es würde mich interessieren, auf welche Informationen du dich dabei beziehst. Amsonsten hat der JIT-Compiler eindeutig mehr Informationen/Quellen zur Verfügung, denn er hat den ganzen Source, der am Ende auf dem Computer vom Benutzer läuft, zur Verfügung und kann damit leichter modulübergreifend optimieren. Er kennt beispielsweise die Größe von fremden Objekten im Speicher und kann beim Zugriff auf Felder die Adresse ausrechnen. Nimm als Gegensatz mal COM, ein Objektmodell, dass es erlaubt, Klassenbibliotheken zur Laufzeit hinzuzulinken. Du kriegst in deiner Anwendung immer eine Indirektion (IDirect3DDevice9**) rein und ein einfacher getter kann auch nicht geinlined werden. Wenn du deine Klasse von einer COM-Klasse ableitest, besteht eine richtig physische Barriere zwischen den Membern der abgeleiteten Klassen und denen der Basisklasse.

Jetzt überleg mal, was ein JIT-Compiler im Vergleich dazu machen kann. Er erhält den Bytecode der Basisklasse und der abeleiteten Klassen.

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.

Ich beziehe mich dabei auf Informationen, die nicht notwendigerweise bei jedem Programmstart gleich sind. Beispielsweise linke ich eine DLL hinzu, dort drin befindet sich die Konstante FOOBAR. Ich kann dir mit Sicherheit garantieren, dass jedes Vorkommen dieser Variable vom JIT mit dem Wert ersetzt wird. Bei einem fertig compiliertem Programm steht dagegen schon fest in deinem Code "rechne Basisadresse + offset" und lies den Wert der Variablen aus". Im Grunde ist es hier das selbe wie mit dem Inlinen von Methoden, die sich in DLLs befinden.

Optimizer schrieb:

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

Ok, das überrascht nicht nur dich, aber unvorstellbar ist das nicht, gebe ich schon zu.

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.

Bei .Net gibt so genannte Application Domains. Vereinfach ausgedrückt erlauben die, ein anderes Programm im selben Betriebssystem-Prozess zu starten, mit der gleichen vollständigen Isolierung der Zustände, aber mit geteilten Resourcen, z.B. bereits JIT-compilierter Code und natürlich nur einmaliger VM-Overhead. Es gibt viele tolle Möglichkeiten, aber die Win32-Altlasten machen bei vielen Dingen noch einen Strich durch die Rechnung. Es ist beispielsweise reichlich unnötig, einen VM-Prozess vom BS-Speicherschutz überwachen zu lassen, wenn man schon garantieren kann, dass keine access violations auftreten. Die Praxis sieht für solche Systeme halt noch eher schlecht aus.

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 ?

Wenn du Daten zwischen Modulen, die in verschiedenen Sprachen geschrieben worden sind, austauschen willst, brauchst du ein gemeinsames Datenmodell. C-DLLs kann jede Sprache benutzen, die sowas wie Pointer oder pass by ref kennt. COM-DLLs kann jede Sprache benutzen, die sowas wie Klassen und Objekte kennt. Es gibt keinen Grund, warum .Net-DLLs oder Java-Klassen nicht in anderen Sprachen benutzt werden können. Im Grunde ist Bytecode nichts anderes als auch ein Objektmodell, das aber keinen Unterschied zwischen deinem Programm und Bibliotheken macht, also ohne künstliche Grenze. Es gibt schon einige Compiler für andere Sprachen, die Java-Bytecode generieren, dazu hatte Gregor mal einen Link. Aber bei der Java VM war das Designziel nicht mehrsprachenfähigkeit. Bei .Net geht es aber eigentlich recht gut (ca. 50 Sprachen).

Natürlich geht nie in jeder Sprache alles, sonst wäre der Sinn von mehreren Sprachen irgendwie weg. Man hat immer nur eine gemeinsame Untermenge an Features zur Verfügung, nicht alle Features stehen jeder Sprache offen. Aber die tollen C-DLLs haben halt einfach keine Features, dann ist ja klar, dass die immer funktionieren.

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.

Dem widerspreche ich. Ich möchte nicht darauf verzichten, von Bibliotheksklassen abzuleiten und Methoden zu ergänzen oder zu redefinieren. All das wäre reichlich inperformant, wenn die Klassen aus irgendwelchen DLLs kommen. Oder stell dir mal vor std::map<> käme aus einer DLL! "Nicht performancekritisch" ist ein statisches System nur, wenn du bereit bist, auf bestimmte Features zu verzichten.

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.

Jede mögliche Optimierung ist gelaufen. Und was ist schlecht daran, wenn erst der JIT optimiert?

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)

Das ist auch genau der Grund, warum die Praxis für Java schlechter aussieht. Aber ich bin mal gespannt, wie .Net Programme in Zukunft laufen werden. Ich bin überzeugt, dass das Konzept eines Zwischencodes überlegen ist. Dabei muss man Sprachen und Reife der Compiler außer Acht lassen. Schon jetzt ist ein C++/CLI Programm mit JIT-Compilierung kaum langsamer als das gleiche C++ Programm.

[Softwareentwickler]

Java überzeugt nicht.

Und aus diesem Grund werden wir auch weiterhin bei der ausgereiften HighLevel-Programmiersprache des bewährten Weltmarktführers bleiben, mit der wir in den vergangenen Jahren hervorragende Erfahrungen gemacht haben.

Die kostet nicht nur nichts, sondern überzeugt auch noch durch einen schnellen Return on Investment durch vorbildliche Sicherheit, Stabilität, Kompatibilität, Performance, Usability, Skalierbarkeit, Multiple Inheritance, echte Templates, Template Metaprogramming, Multi-Paradigms, funktionale Aspekte und Kontinuität in der Sprachpolitik.

Und das ist es schliesslich, worauf es Experten wie meinen hochqualifizierten Softwareentwicklern und mir im harten Tagesgeschäft des internationalen Wettbewerbs ankommt.

Ideologisch motiviertes Bastelwerk, halbherzig zusammengeschustert durch praxisfremde Marketingstrategen mit Zwangs-OOP-Fixierung, hat keinerlei Chance, will man sich tagtäglich aufs Neue den Herausforderungen der Globalisierung und der mit dieser einhergehenden ständig wechselnden Anforderungen an das Entwicklungswerkzeug erfolgreich stellen. Da können einfach nur Lösungen von Profis für Profis zum Einsatz kommen, die hervorragend durch das Stroustrupsche Meisterwerk abgedeckt werden.

[Gregor]

frenki schrieb:

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.

Meine These: Wenn man sich für eine genutzte Bibliothek als Programmierer verstellen muss, weil sie komplett anders als der Rest des Programms funktioniert, werden hiermit auch Bugs verbunden sein, die im Programm entstehen. Aus meiner Sicht ist das also eine Bug-Quelle. Zudem wird das Programm an dieser Stelle schlechter wartbar sein und und und.

Mit andere Worten: Es gibt auch aus Sicht des Nutzers des Programms Gründe, die gegen SWT sprechen. Wenn eine genutzte Bibliothek nicht gut in das Programmiermodell passt, dann wird die Qualität der Software dadurch leiden.

...nur so ne Meinung.