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

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

[Gregor]

rapso schrieb:

java wurde nicht entwickelt um
[...]
3. allround eingesetzt zu werden

Hä? Was glaubst Du, warum Diskussionen wie diese überhaupt entstehen? Weil sich die Anwendungsgebiete von Java und C++ nicht überschneiden? Wahrscheinlich nicht. Die Anwendungsgebiete überschneiden sich in weiten Teilen. Und Java wird in sehr sehr vielen Bereichen eingesetzt (wenn man mal von Treibern absieht). Die Entwicklung von Desktopanwendungen gehört in jedem Fall auch zu den Anwendungsgebieten von Java. Und das ist auch ein Bereich, in dem die Java-Nutzung zunehmen wird.

[optimierer]

Es muss endlich mal eine vernünftige Alternative zu Swing entwickelt werden. Swing ist rufschädigend für Java.

[gurkenesser]

hab nur ich das gefühl, oder sind die meisten hier c++ programmierer, die keine arbeit finden, weil auf dem markt nunmal mehr java als c++ programmierer gesucht werden, und deshalb nichts besseres zu tun haben als ihren frust hier rauszulassen indem sie ihr halbes "expertenwissen" propagieren zu versuchen?

[TGGC_|work]

gurkenesser schrieb:

hab nur ich das gefühl, oder sind die meisten hier c++ programmierer, die keine arbeit finden, weil auf dem markt nunmal mehr java als c++ programmierer gesucht werden, und deshalb nichts besseres zu tun haben als ihren frust hier rauszulassen indem sie ihr halbes "expertenwissen" propagieren zu versuchen?

Bloß kein Neid. f'`8k

Bye, TGGC

[centaur warchief]

gurkenesser schrieb:

hab nur ich das gefühl, oder sind die meisten hier c++ programmierer, die keine arbeit finden, weil auf dem markt nunmal mehr java als c++ programmierer gesucht werden, und deshalb nichts besseres zu tun haben als ihren frust hier rauszulassen indem sie ihr halbes "expertenwissen" propagieren zu versuchen?

hehe, kommt mir auch so vor :0)

[Gast]

Hmm, schlagt mich aber ich denke das mit den JAVA Jobs hängt mit dem Anstieg der Web- und Mobilprojekte zusammen. C++ wird halt mehr für den Rest eingesetzt, diese Menge wächs nicht so stark an wie Handy und Web und daher werden nicht weniger C++ Jobs angeboten als früher.

[groovemaster]

Gregor schrieb:

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

Deshalb habe ich ja von Anfang an geschrieben, dass Theorie und Praxis sich nicht überdecken. Vermutlich habe ich unterschätzt, dass einige Leute (Grüsse an Opti ) das falsch verstehen. Ich selbst glaube auch, dass in einer VM (nicht nur bezogen auf Java) viel Potenzial steckt. Und dass diesen vermutlich in weiten Bereichen der Softwareentwicklung die Zukunft gehört. Ich habe nur manchmal das Gefühl, dass einige JVM Verfechter glauben, dass es nur eine Frage der Zeit ist, bis die komplette Softwarewelt Java spricht. Das wird aber nicht passieren. Schon deshalb nicht, weil es nicht nur Web-Applikationen gibt oder GUI Anwendungen mit Klicki-Bunti Interface.

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.

Das ist 'ne ganz einfache Rechnung.

x + y + z = e1 // c++
w + x + y + z = e2 // java

x ist die Laufzeit des Programmstarts, also das, was noch vor main passiert. y ist die Laufzeit des Rumpfprogrammes, also alles in main. Und z das Programmende, also alles nach main. Bei Java kommt noch w hinzu, die JIT Kompilierung. Jetzt stellen wir die Formeln entsprechend um, und verbinden sie zu einer. Dabei erhalten wir:

e1 = e2 - w

Und wenn wir natürlich davon ausgehen, dass alle Werte weder negativ noch null sind, bedeutet das

e1 < e2

Wie gesagt, das ist vollkomem praxisfern. So sieht aber nunmal verallgemeinert die Theorie aus.

Optimizer schrieb:

Konstanter Aufwand ist theoretisch völlig bedeutungslos.

Praktisch, nicht theoretisch.

Optimizer schrieb:

Die besagt, dass nur 20% des Codes eines Programms für die Performance von Bedeutung sind.

Das kann dann aber sicherlich keine allgemeingültige Regel sein. Immerhin gibt es nicht immer GUI. Mittlerweile kaum noch, aber während meiner Ausbildung hatte ich zB sehr viel mit Automatisierungstechnik zu tun. Und dort sind 100% der Anwendung Performance relevant. Dieses läuft zyklisch, und wenn die CPU es nicht schnell genug verarbeiten kann, wird die Taktzeit zu hoch und ist damit unbrauchbar. Weil dann zB Signale zu lange brauchen, bis sie geschaltet werden. Oder geschaltete Eingänge erst zu spät "registriert" werden. Und GUI gibts da nicht. Wenn überhaupt, dann als separates Panel über eine externe Schnittstelle.

Optimizer schrieb:

Nein. Er kennt sie nicht gut genug.

Lassen wir es besser sein. Zuerst kennt er sie gar nicht. Jetzt nicht gut genug. Was kommt wohl als nächstes?

Optimizer schrieb:

Ich habe doch vom Inlining gesprochen.

Ich aber nicht. Punkt. Zumal dein Beispiel mit dynamischen Bibliotheken schon ein konretes Anwendungsszenario beschreibt. Hat also bei einer allgemeinen theoretischen Betrachtung nix verloren.

Optimizer schrieb:

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.

Du machst dir das zu einfach. Sicherlich ist die Möglichkeit, eine CPU durch die JIT Kompilierung besser auszunutzen, gegeben. Aber ähnliche Möglichkeiten hat man bei C++ ja auch. Das muss ja nicht immer nur bei der Kompilierung selbst passieren. Man kann auch zur Laufzeit die Fähigkeiten einer CPU auslesen. Und dann zB einen Funktionszeiger entsprechend umbiegen. Und wie gesagt, verschiedene Kompilate für verschiedene Prozessoren würde ich nicht als "exotisch" bezeichnen. In dem Ausmasz, wie du es übertrieben konstruiert hast, natürlich nicht.

Optimizer schrieb:

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

Ach, tatsächlich? Gut das wir mal darüber geredet haben. Aber was die Vorteile nun sind, hast du mir immer noch nicht erklärt. Sofern ich dich richtig verstehe, profitiert davon ja nur die Runtime, aber nicht der main Teil.

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.

Naja, ganz so einfach ist es natürlich nicht. Du musst, zumindest bei C++ Anwendungen, immer noch zwischen Load- und Runtime Linking unterscheiden. Bei Load-Time Linking wird im Grunde das gleiche gemacht, wie bei der JIT Kompilierung. Die "richtigen" Adressen werden erst zur Laufzeit, also beim Beginn der Anwendung, in den Code eingefügt. Und bei Runtime Linking wüsste ich jetzt nicht, was eine VM da besser machen könnte. Zumindest nicht, wenn die Maxime gelten soll, dass nur einmal zu Beginn der Anwendung die JIT Kompilieirung erfolgen soll und somit keinen negativen Einfluss auf die Laufzeit des eigentlichen Programmes haben soll.

Optimizer schrieb:

Ich bin der Anfang (und das Ende).

Manchmal habe ich echt das Gefühl, _du_ bist zwar nicht Deutschland, aber zumindest TGGC.

Optimizer schrieb:

Ich habe es doch begründet.

Du hast zwar einige Detailbeispiele aufgezählt, die sich im Rahmen des Threads natürlich mit der Performance befassen. Aber dass JIT Kompilierung "insgesamt völlig überlegen" ist, ist für mich damit noch lange nicht begründet. Was nicht heissen soll, dass ich dir widersprechen will. Ich habe nur was dagegen, wenn Leute solche Propagandasprüche zum Besten geben, ohne dafür eine einleuchtende und vor allem ausreichende Erklärung zu liefern.

Optimizer schrieb:

Das Problem ist: Du hast deine Aussage über Langsamkeit explizit mit dem Interpretieren begründet.

Was, wie ich dir oben bewiesen habe, im gesteckten Rahmen auch logisch sein sollte. Dass das mit der Praxis nix zu tun hat, habe ich ja nun auch schon mehrfach erwähnt. Und wenn dich das Wort stört, dann denk dir halt einfach JIT Kompilierung.

[rapso]

Gregor schrieb:

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

das allermeiste sind scheinbar tools, keine sprachen.

Gregor schrieb:

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?

schön dass du das "-zeichen nicht verstanden hast, aber eben das sollte es implizieren.

Gregor schrieb:

In der Wirtschaft gibt es immer Grenzen bezüglich des Budgets, der Zeit usw.. Niemand ist da bereit, für etwas perfektes zu zahlen.

natürlich ist man das, es hängt nur von der firma ab, nicht umsonst gibt es mathematische analysemethoden für software mit der du mathematisch nachweisen kannst, dass ein ausdruck, eine funktion, ein programm usw. fehlerfrei ist. du kannst davon ausgehen, dass raketentriebwerke mit einer so getesteten/berechneten software laufen.
große firmen die software für eigene zwecke erstellen legen auch sehr viel mehr wert auf die qualität, als firmen die software verkaufen. das ist auch logisch, bei verkauf-software ist es das ziel damit geld zu verdienen, dass die software raus ist und solange du keine grobe/fahrlässige fehler hast, ist es erstmal egal, hauptsache der kunde hat bezahlt (bestes beispiel ist zZ photoshop, das in der neusten version derart schlecht ist, dass man damit absolut nicht proffesionell arbeiten kann). auf der anderen seite hast du die intern genutzte software, jeder fehler darin hat für das ende der produktion viel weitreichendere folgen, z.b. falsches runden von zahlen bei einer fräsemaschine. das ist deswegen oft derart wichtig, dass obwohl es die benötigte software schon gibt, die firmen ihre eigene schreiben mit eigener QA dafür.

Gregor schrieb:

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.

das ist richtig für applikationen die schnell mal gemacht werden müssen bis zu einem termin. aber es gibt auch software bei der es andere zielsetzungen gibt wie eben z.b. performance und da erlaubt dir java an vielen stellen überhaupt nicht einzugreifen, man muss auf das generische system hoffen, und hoffen dass die optimierung die man vielleicht macht, dann auch in den nächsten versionen des JIT so interpretiert werden. ich kann beim programmieren mit c für ne arm cpu festlegen welche dinge im cache/scratchpad sein sollen und welches allignment benutzt werden soll, ich kann mir die adresse von gewissen teilen des speichers besorgen und die auf einer x86 cpu in den cache "pingen" wie es vom memorycontroller her optimal ist.
das kann ich mit java nicht, aber java wurde ja auch nicht für diese performancesachen gemacht.

Gregor schrieb:

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.

es geht nicht um die gehälter der fertigstudierten-vollverdiener. es geht darum, dass es sehr viele firmen gibt, die mit java (und früher VB) applikationen entwickeln lassen, die keine vollprofis benötigen. so gibt es dann viele praktikaten, auszubildene usw. die mit VB/Java/etc programme für den markt schreiben, weil man es ihnen numal zutraut, eher als dass die einfach software mit c++ schreiben können.
um es klarzustellen: ich sage nicht, dass alle java-programmierer idioten sind, sondern dass man "idioten" lieber java gibt um ein produkt zu programmieren als c++, bzw. würde man alternativ einen erfahrenen programmierer mti c++ software erstellen lassen und den "idioten" erstmal voll ausbilden bevor er mit c++ software machen darf die man ihm schon lange mit java zutrauen würde.

und in zukunft wird es weiter in die richtung gehen, dass man einerseits programmierer "entmündigt" und durch sehr viel vorgefertigtes die arbeit abnimmt. aber das ist auch klar, rechner sind 100mal schneller als vor 8 jahren, die gleiche software muss aber nicht 100mal schneller laufen. was macht man also mit der ganzen leistung? man tauscht sie gegen entwicklungsgeschwindigkeit. wo jemand früher also nen monat an einem programm schreiben mußte, darf er nun in einer woche ein ebenbürtiges programm entwickeln... und das war eben mit ein ziel von java. ich weiß nicht, was daran schlimm sein sollte.
das ist doch überall so
- motoren verbrauchen die hälfte gegenüber früher -> fahrzeuge wiegen das doppelte.
- akkues haben doppelte kapazität -> handys/notebooks usw. verbrauchen das doppelte
- graphikkarten haben zigfache leistung -> spiele haben gleiche fps, dafür bessere graphik

[DEvent]

Ich habe den Thread jetzt ziemlich genau vefolgt und ist echt interessant bis jetzt. Aber groovemaster, du langweilst langsam. Du trollst jetzt einfach nur rum.
Optimizer hat etliche sehr gute Argumente genannt wieso ein JIT besser optimieren könnte als es ein C++ Compiler je kann.

x + y + z = e1 // c++
w + x + y + z = e2 // java

tolle Rechnung
Ich würde die Rechung eher so schreiben:
x1 + y1 + z1 = e1 // c++
w + x2 + y2 + z2 = e2
denn weder x, y noch z sind bei C++ und Java gleich.

Ein JIT kennt einfach das System auf dem das Programm läuft zu 100%. Wärend man bei C++ doch nur fürn x beliebigen x86 compiliert. Ausserdem kennt der JIT alles von dem Code. Egal ob es dein Programm ist oder Librarys von Marsmännchen. Somit kann er nun das komplette Programm genauestens optimieren. Wärend der C++ Compiler das Programm nur für einen Standard x86 optimiert und die fremd-Libs nicht anfassen kann.

Ausserdem ist die JIT Compelierung in O(n) also in konstanter Zeit, also völlig und total vernachlässigbar.

[gurkenesser]

rapso schrieb:

Gregor schrieb:

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

das allermeiste sind scheinbar tools, keine sprachen.

lol o.O
- eine programmiersprache generiert gar nix
- bytecode generieren tun compiler
- compiler sind tools
- auf der verlinkten seite werden compiler (tools) aufgelistet, die aus bestehenden und neuen sprachen java bytecode generieren

du weißt was 'scheinbar' bedeutet

mfg

[DEvent]

große firmen die software für eigene zwecke erstellen legen auch sehr viel mehr wert auf die qualität, als firmen die software verkaufen. das ist auch logisch, bei verkauf-software ist es das ziel damit geld zu verdienen, dass die software raus ist und solange du keine grobe/fahrlässige fehler hast, ist es erstmal egal, hauptsache der kunde hat bezahlt (bestes beispiel ist zZ photoshop, das in der neusten version derart schlecht ist, dass man damit absolut nicht proffesionell arbeiten kann). auf der anderen seite hast du die intern genutzte software, jeder fehler darin hat für das ende der produktion viel weitreichendere folgen, z.b. falsches runden von zahlen bei einer fräsemaschine. das ist deswegen oft derart wichtig, dass obwohl es die benötigte software schon gibt, die firmen ihre eigene schreiben mit eigener QA dafür.

Was hat das mit Java zu tun ? Rechnet Java falsch oder rundet es falsch ?
Ich würde sagen daduch, das man die Speicherverwaltung Profis überlässt, die Tagein Tagaus nichts anderes machen als den GC zu optimieren, sorgt man dafür das die Software sicherer ist.
Ein C++ Programmierer muss sich sorgen machen über die normale Implementation der Algorithmen und um die Speicherverwaltung. Bei Java und C# hat man es getrennt: Ein Spezialist arbeitet an der Speicherverwaltung, ein anderer an den Algorithmen.
Ausserdem ist es durch den wegfall der Zeiger eher sicherer :p

ich kann beim programmieren mit c für ne arm cpu festlegen welche dinge im cache/scratchpad sein sollen und welches allignment benutzt werden soll, ich kann mir die adresse von gewissen teilen des speichers besorgen und die auf einer x86 cpu in den cache "pingen" wie es vom memorycontroller her optimal ist.

Das ist genau das was der JIT und die Hot-Technologie macht. Wenn es sich lohnt kann der JIT den Code genau auf sowas optimieren und zwar zur Laufzeit des Programmes.

[Jester]

DEvent schrieb:

Ausserdem ist die JIT Compelierung in O(n) also in konstanter Zeit, also völlig und total vernachlässigbar.

Ja was denn nun? O(n) oder konstant?