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

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

[Gast]

*rofl*

[DEvent]

Jester schrieb:

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?

Ahh stimmt. Ich meinte linear. Linearer Zeitaufwand ist aber genauso vernachlässigbar.

[genie]

P = NP!!!!!!!!!!!!!!!!111111111111111 (O(n!) ist vernachlässigbar)

[DEvent]

Die Mods sollten den Thread in die FAQ reinstellen

[net 0]

DEvent schrieb:

Die Mods sollten den Thread in die FAQ reinstellen

java vs. c++ threads gibts doch viele hier und immer füllen sie mehrere seiten...

[Gregor]

@rapso: Ok, habe deinen Beitrag vorhin wohl etwas falsch interpretiert. Mit deiner Erklärung bin ich mehr oder weniger einverstanden.

Bei den aufgelisteten Sprachen gibt es sicherlich auch noch ne ganze Menge anderes Zeug drin, keine Frage. Allerdings sind auch einige interessante Sprachen/Compiler enthalten, die Bytecode produzieren.

Man braucht aber letztendlich sowieso nur ganz wenige Sprachen. Ich habe noch nie etwas anderes als Java verwendet, um Code für die JVM zu produzieren. Nicht weil es nichts anderes gäbe, sondern weil der diesbezügliche Bedarf einfach nicht da ist. Interessant könnten zum Beispiel Sprachen wie "Groovy" sein. Auch irgendwelche Javavarianten von Prolog oder Lisp könnten für mich irgendwann interessant werden. Aber die meisten Sprachen bieten eigentlich nichts, was mich dazu bringen würde, sie in diesem Umfeld einzusetzen.

[Gast]

Ich will mich ja als C++ Neuling nicht großartig in das Fachgespräch einmischen, aber wenn der JIT Compiler ähnlich performant oder sogar schneller als eine C oder C++ Implementierung ist, warum werden dann z.B in JAVA oder C#(die VM dort hat doch auch JIT-C oder?) nicht performante Anwendungen geschrieben?

[rapso]

Optimizer schrieb:

also beispielsweise for( int i; i < array.length; ++i ); Warum sollte er jetzt nicht für den Prozessor geeigneten Code generieren können?

schönes beispiel, ich erweiter es ein wenig um es dir verständlich zu machen was für informationen verloren gehen. also, lass uns annehmen, dass in dieser schleife alle werte des arrays aufeinander addiert werden. ala

int array[] = new int[256];
.
.
.
int Sum=0;
for(int a=0;a<array.len;++a)
  Sum+=array[a];
return Sum;

hat natürlich ein wenig overhead das ganze, das summieren hat den allerwenigsten einfluss auf die ausführungsgeschwindigkeit. sowas sollte ein compiler dann also optimieren indem er die schleife ausrollt. z.b.

Sum+=array[a++];
Sum+=array[a++];
...

ich hab zwar schon ewig nicht mehr java-bytecode-assembler gecodet, aber in pseudocode dürfte dabei etwas wie

bipush 0 //a auf stack legen
load array //pointer vom aktuellen array laden

iaload //erstes arrayelement auf stack schreiben und auf stsack legen
... hier verrechnet er nun Sum mit dem stackelement
iinc 1,1 //addiert auf a eins drauf
iaload //zweites arrayelement auf stack schreiben und auf stsack legen
usw...

als assembler wird er also eine var vom array laden, dann aufsummieren und dann a inkrementieren. das ist auf einer ARM-cpu super, dürfte in 2instructions pro schleifendurchlauf resultieren, schneller geht es nicht. auf x86 generiert er ebenfalls diese instruktionen, leider ist es sehr langsam, weil die ladefunktion immer auf das resultat vom increment warten muss, der richtige weg wäre gewesen mit konstanten zu indizieren (das wiederrum geht auf arm nicht und würde emuliert werden).

man kann natürlich versuchen für diesen trivialfall eine optimierung einzubauen, ist wahrscheinlich auch in den JIT für die verschiedenen plattformen drinne, vermutlich sogar mit SIMD-optimierungen. aber wie gesagt, das ist ein trivialfall der in den ersten JIT nicht erkannt wurde und man mit bytecode-assembler ein javaprogramm trotz JIT noch locker doppelt so schnell bekommen konnte. bei komplexeren beispielen kann der JIT leider nicht hellsehen was die absicht im source war.

Optimizer schrieb:

...

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.

s.o., informationen sind meine erfahrungen mit bytecompilern wie java, cg usw.

Optimizer schrieb:

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.

1. das ist leider naiver glaube, dass das performancerelavant ist. das verrechnen einer adresse passiert bei x86 aufgrund der adressierungsmodi meist kostenlos (0 performance relevanz).
2. in den allermeisten fällen ist es nicht möglich die absolute adresse zu errechnen, weil man sonst für jeden datenbereich den eigenen code bräuchte der auf diesen datenbereich optimiert ist (das wäre weit aus langsammer), aus diesem grund gibt es weiterhin indirektion über pointer.

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.

ja, COM ist ein echt unschönes interface, hat aber nichts mit eine sprache zu tun, auch java muss über die JVM auf externe bibliotheken zugreifen, ansonsten gebe es nichtmal ein println.
das hat aber nicht wirklich viel damit zu tun, dass man beim compilieren mit c++ meist alle sourcen von den verwendeten libs hat so wie bei java der JIT die sourcen der libs hat. nur sehr selten hat man wirklich externe libs/dlls, wenn man eine applikation mit mehreren hundert klassen hat, sind vielleicht 5DLLs dabei die keine performancekritischen schnittstellen haben, wenn es nicht absolut nötig ist (z.b. spiel zu d3d9.dll)

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

wie gesagt, zumeist hat man alle sourcen der libs die man verwendet, nein nicht nur bei linux, auch wenn man kommerzielle libs verwendet z.b. unreal engine3, bekommt man die vollen sourcen und der c++ compiler kann direkt auf das native format compilieren ohne zwischendurch informationen zu verlieren.

Optimizer schrieb:

...

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.

das hängt mit der unterschiedlichen definition von "konstante" ab und überlebt keinen direkten performancevergleich.
eine konstante von java ist mit einem enum bzw #define von c++ vergleichbar, nicht jedoch mit einer const. aus diesem grund hast du nach dem kompilieren die gleichen optimierungen wie bei java.
eine c/c++ const ist als const anders definiert. bei z.b. einer static const ist die adresse immer gleich für die ganze app, je nach OS kannst du dann diese const zur laufzeit auch noch umstellen (bei windows kann man meines wissens nach mit ein paar undokumentierten api-calls das segment in dem die const liegt write-able machen und überschreiben).

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.

ich bezog mich hier auf java, aber auch da wäre es sicherlich möglich beim verknüpfen von OS und JVM sowas zu integrieren, gibt es auf dem SunOS meines wissens nach auch bei der serverversion der JVM.

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.

tjo, aber da der speicherschutz von der hardware 4free ist, who cares?

Optimizer schrieb:

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.

nicht nur unterschiedliche features, sondern auch auslegungen und java wurde nicht für performance ausgelegt, no no und c++ nicht für write once, run everywhere.

Optimizer schrieb:

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.

wie ich schon sagte, meistens hat man alle sourcen zu verfügung. ein modul/eine lib ist keine aussage darüber, dass es physikalisch getrennt ist. ich kann mir die boost dazucompilieren oder die nebulaengine und irgens wird festgelegt, dass die in seperaten dlls sein müssen. somit bleib ich dabei, dass dlls nur komplett abgetrennte bereiche darstellen und meistens nicht performancekritische schnittstellen haben (ausnahmen sind nunmal dinge wie z.b. d3d9).

Optimizer schrieb:

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?

wenn du dich ein wenig mehr mit compilern beschäftigst, siehst du dass es viel einfacher ist code zu optimieren der unoptimiert ist, als optimierten source/bytecode. das trifft z.b. auch auf shadercompiler zu und wird von den herstellen explizit gesagt, dass man z.b. beim compilieren von cg zu glsl unopptimierten code machen soll, weil dann die compiler mehr ihr eigenes potential ausspielen können.
ein compiler kann z.b. eine normalisierungs eines vectors vornehmen. vielleicht kann er sogar so intelligent sein und zwei vectoren mit nur einer reciproken berechnung normalisieren
pseudocode

vec V1, V2;
...
float L1=V1.Len();
float L2=V2.Len();
float iL=1.f/(L1*L2);
V1*=iL*L2;
V2*=iL*L1;

dieser code ist vermutlich schneller als wenn er zwei divisionen hätte... oder? leider würde der nächste compiler der drüber geht nicht mehr den sinn dieses codes erkennen. also dass man v1.normalize(); machen möchte. falls nun die cpu ne optimierung hat für ein superschnelles normalize, würde dieses potential nicht ausgenutzt werden.

aus diesem grund sollte code unoptimiert möglichst als source direkt auf nativen microcode compilert werden.
ist in etwa so wie beim packen. gibst du einem guten packer rohdaten, generiert er dir zumeist bessere final-packergebnisse, als wenn du ihm die schon vorgepackt von anderer software gibst.

Optimizer schrieb:

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.

[/quote]
ich kenne viele beispiele, dass es dem nicht so ist. ich kenne z.b. einen sehr guten programmierer der auf .net schwört und raytracer an der uni in utah schreibt. trotz seines wirklich guten wissens und könnens der sprache und der materie waren die raytracer der meisten anderen die in c/c++ programmiert wurden im schnitt ca 4mal schneller (laut seiner aussage), aber es stört ihn nicht wirklich, da sein tracer sehr gut designed und erweiterbar ist, deswegen hat er gegen ende sehr viel weniger zeit mit programmieren verbringen müssen als die anderen (dafür aber sehr viel mehr gewartet bis sein tracer fertig ist).
und ich hab sehr viele andere beispiele die das selbe sagen.