Unterschiede C++/C#

otze

Manuelh87 schrieb:

und soviele würmer wie über java reinkommen kann ich mir nicht vorstellen das es diese höhere ebene irgendwie nutzt aber das lass ich mal dahingestellt. Bei Punkt optimierungen bin ich mir aber ziemlich sicher dass das at runtime schwachsinn ist, sry.

Dann muss ich dir leider sagen, dass deine vorstellungen wenig mit der realität gemeinsam haben!

hier 2 links zu compilierungstechniken
link1
link2

zu erwähnen ist desweiteren noch, dass jit compiler besser wissen was gecached werden muss oder kann als normale compiler was wieder eine bessere performance bringt

für mehr infos musst du dann im internet suchen

größere optimierungen betreiben(der c++ compiler macht fast nur mikro optimierungen)

Achja nur micro optimierungen... sry aber ich kenne keinen compiler der c++ compiler heißt. Da musst du schon genauer werden. Ich kenne den MSVC++ gut für den ist optimierung ein fremdwort und ich kenne aber auch den gcc und kann nur sagen das der sicher nicht nur micro optimierungen macht. (Kleiner Tip man muss es händisch einschalten vielleicht lags bei dir daran! )
Würd mich aber interessieren woher du das hast.

natürlich gibt es nicht "den" c++ compiler, aber alle benutzen dieselben techniken. ein compiler kann keine größeren zusammenhänge erkennen. in kleinen bereichen wie loop unrolling oder inlining kommt er sehr gut klar, und das macht er dann auch soweit man ihm dies erlaubt. andererseits kann er sowas nicht optimieren:

map<string,int> mymap;
// map mit werten bestücken...
//...
//was mit der map machen
if(mymap.find(myname)!=mymap.end()){
    int value=map.find(myname)->second;//den zweiten aufruf von find kriegt er nicht weg
}

und wieso? der compiler weis nicht, dass sich in der map zwischen den aufrufen nichts ändert.(Kleiner tipp: bei zweifeln selber den compiler anschalten und asm output anschauen )

und wie willst du das jetzt praktisch mit asm machen (templates mal weggelassen); Du hast theorethisch schon recht das man alles in asm machen kann was auch in c++ geht, gut gelesen. Aber du musst dir auch praktisch überlegen wies aussieht und wieviel aufwand es ist und am ende kommst du bei dem ohne templates nur schwer auf die gleiche lösung... (müsstes ja ne proc machen und hast damit schon mal ein paar instructuions mehr.

es ging nur um deinen geschwidigkeits schwanz vergleich, und im zweifelsfall verliert der beste compiler den, wenn ihn jemand wirklich schlagen will! mehr wollte ich nicht sagen. wenn du sagst "der compiler kann einen schnelleren code erzeugen als ein asm programmierer" dann liegst du nur dann richtig, wenn der asm programmeirer keine lust hatte das maximum rauszuholen(oder es einfach nicht kann)! Vom zeit aspekt war weder von mir noch von dir bis dato die rede, deshalb hinkt das argument ganz mächtig(weil es eine verschiebung der ebene ist).

Manuelh87

otze schrieb:

map<string,int> mymap;
// map mit werten bestücken...
//...
//was mit der map machen
if(mymap.find(myname)!=mymap.end()){
    int value=map.find(myname)->second;//den zweiten aufruf von find kriegt er nicht weg
}

Ärm den code kann er nichtmal compilieren

Das zweite mit praksis hast ned checkt sry! Ich meine klar kann man das gesamte programm ohne procs und so macht nur braucht man dazu 20 jahre wenn man alles so von hand macht... das ist ne theory - praksis sache... Theoretisch geb ich dir vollkommend recht nur praktisch ist glaub ich die c++ methode die bessere. Trotzdem hät ich gerne deine geschwindigkeits schwanz funktion die schneller ist als meine beschriebene gesehen... Es gibt auch funktionen die einfach schon mit c++ am maximum sind. Zugegeben kommt sicher nicht allzuoft vor aber bei dem beispiel bin ich mir ziemlich sicher... Und selbst wenn du eine asm funktion findest (wie auch immer) die schneller ist ist die c++ methode noch immer praktischer und nochimmer viel schneller als die normal gernerierte...

Wegen dem java dynamics zeug.... halt ich nochimmer für ziemlichen müll! Kann mir nicht vorstellen das er das was er mit den analysen verschießt wieder mit seinen optimierungen reinholt. Hab auch nirgendst was gesehen was das im endeffekt bringen soll.

Und zu deinem missratenen beispiel... ich mein varum sollt ich denn 2x die funktion aufrufen? Ist das nicht total bescheuert. Ich mein sowas würd ich nie machen. Ich mein sry aber wenn du den größten deppen-code nimmst dann kanns schon sein das irgendwann java mit seinen profi-optimierungen schneller ist... ich mein ein wenig muss der coder schon noch mitdenken!

Nagut ich werd also nichtsmehr von wegen sagen das der code besser ist als asm da es auch hier möglichkeiten für inline + templates gibt die ich bei dieser aussage nicht bedacht habe. Dafür entschuldige ich mich auch vielmals.

Bitte nicht denken ich mag nur nen kleinen flame machen... interessiert mich ja wirklich was ihr dazu zu sagen habt! Nur weil ich mir was nicht vorstellen kann heißt das ja nicht das es nicht existiert... also meine (oftmals) dümmlichen antworten nicht persöhnlich nehmen

cu Manuelh87

Michael E. schrieb:

Ich stimme mit Gregor überein, ich erinnere mich an keinen einzigen Punkt in diesem Thread, in dem ich das nicht tue. Ihm seine soziale Kompetenz abzusprechen ist eine Sache, die ich nicht nachvollziehen kann, weil er sich absolut normal verhalten kann. Aber dann auch noch seine sachliche Kompetenz zu bestreiten find ich ungeheuerlich

full ack. Ich würde jetzt gerne noch ein paar Hass-Smileys hinzufügen, aber mehr als 10 kann man sowieso nicht posten und mit dem hier zitierten sind es nur noch 9, das reicht also nicht.

Manuelh87 schrieb:

Ärm den code kann er nichtmal compilieren

Ui, böse. otze, hiermit verwarne ich dich offiziell, nie wieder beispielcode zu posten, der nicht vollständig und nur zur Verdeutlichung dienen soll. Ich bin außerdem ein netter Mensch und helfe dir:

#include <map>
#include <string>

using namespace std;

int main()
{
	map<string,int> mymap;
	// map mit werten bestücken...

	mymap.insert(pair<string, int>("hi", 5));
	string myname = "hi";

	//was mit der map machen
	if(mymap.find(myname)!=mymap.end()){
		int value= mymap.find(myname)->second;//den zweiten aufruf von find kriegt er nicht weg
	}
}

Wegen dem java dynamics zeug.... halt ich nochimmer für ziemlichen müll! Kann mir nicht vorstellen das er das was er mit den analysen verschießt wieder mit seinen optimierungen reinholt. Hab auch nirgendst was gesehen was das im endeffekt bringen soll.

Klicke bitte bloß nicht auf die ganzen Links die hier inzwischen gepostet wurden. Jeder Satz von dir, der irgendwas aussagen soll beginnt mit "halte ich für blödsinn...", "kann ich mir nicht vorstellen..." aber nirgendwo kann ich einen Informationsgehalt oder Argumente ausmachen. Woher nimmst du deine Überzeugungen?

Und zu deinem missratenen beispiel... ich mein varum sollt ich denn 2x die funktion aufrufen? Ist das nicht total bescheuert. Ich mein sowas würd ich nie machen. Ich mein sry aber wenn du den größten deppen-code nimmst dann kanns schon sein das irgendwann java mit seinen profi-optimierungen schneller ist... ich mein ein wenig muss der coder schon noch mitdenken!

Natürlich ist das bescheuert, deshalb kannst du jetzt auch ein wenig abstrahieren und dir Situationen vorstellen, wo es nicht so extrem offensichtlich ist wie hier. Ich finde das ziemlich beeindruckend, wenn ein Compiler sowas optimieren kann. Man muss das ja mal auf allgemeinerer Ebene betrachten, wenn ein Compiler sowas drauf hat, kommt dir das überall zu Gute. Du erwartest doch von einem C++ Compiler auch, dass wenn du ein großes Objekt by value zurückgibst, er Code generiert, der die Adresse übergibt und das Objekt direkt schreiben lässt. Trotzdem ist es für dich geil, wenn du es so schreiben kannst, als würde es zurückgegeben werden, weil du dann gleich weiterhacken kannst:

foo.getMyFatObject().someMethod();

Das ist halt schöner als

Class bar;
foo.getMyFatObject(&bar);
bar.someMethod();

Diese Problematik existiert so in Java nicht und daher erwartet man sich andere Abstraktionsmöglichkeiten, ohne dafür bezahlen zu müssen.

Nur weil ich mir was nicht vorstellen kann heißt das ja nicht das es nicht existiert...

Das hört sich doch gut an.

Walli

Manuelh87 schrieb:

naja warum ich so begeistert bin von inline + template in kombination?? hab ich glaub ich schon erklärt und wärst nicht glaub der glaubts halt eben nicht... nicht mein problem. Aber er sollte nicht dumm reden (supercodes) denn wie gesagt gibt es so "Supercodes" Hab mich angefangen für sowas zu interessieren wie ich auf flipcode gestöbert hab...

Ich habe nie bestritten, dass es Supercodes gibt, mir war nur neu, dass sie aktuellen Compiler schon damit umgehen können, obwohl Mathias Fradmann sein Buch noch nicht herausgebracht hat.

Manuelh87

Optimizer schrieb:

Klicke bitte bloß nicht auf die ganzen Links die hier inzwischen gepostet wurden. Jeder Satz von dir, der irgendwas aussagen soll beginnt mit "halte ich für blödsinn...", "kann ich mir nicht vorstellen..." aber nirgendwo kann ich einen Informationsgehalt oder Argumente ausmachen. Woher nimmst du deine Überzeugungen?

Bin eben sehr selbstbewusst und nehme meine überzeugung aus der luft
Nein, ernsthaft Ich hab natürlich auf eure links geklickt... sogar noch weiter geklickt auf die "unter" links
Nur hab ich da nur wertloses qua qua gelesen und keinerlei ergebnisse dieser angeblich so tollen optimierungen. Außerdem bezweifel ich mal einfach das diese optimeriungen soviel rausholen wie beim analysieren reingesteckt wird. Ich mein er kann ja nicht alles optimieren. Und der fakt das du es auch bemerkenswert findest das er das kann unterstreicht doch auch das es recht komplex ist sowas zu finden ergo auch recht viel leistung verbraten wird. Gut muss nicht unmengen sein aber ich mein weil er eine von 10 stellen gut optimiert kann er noch immer bei den andren 9 soviel zeit mit analysieren verbraten das er im endeffekt langsamer ist als vorher oder zumindest den performenc-gain zunichte macht... also wie du siehst hab ich mir schon auch gedanken gemacht... Aber ich bin offen für kritik

cu Manuelh87

Manuelh87

Walli schrieb:

Ich habe nie bestritten, dass es Supercodes gibt, mir war nur neu, dass sie aktuellen Compiler schon damit umgehen können, obwohl Mathias Fradmann sein Buch noch nicht herausgebracht hat.

Hör ich da ironie raus? pf... keine Supercodes... als nächstes willst du mir erklärenen das es keinen Weinachtsmann gibt

Manuelh87 schrieb:

Gut muss nicht unmengen sein aber ich mein weil er eine von 10 stellen gut optimiert kann er noch immer bei den andren 9 soviel zeit mit analysieren verbraten das er im endeffekt langsamer ist als vorher oder zumindest den performenc-gain zunichte macht...

Der Performance-Gewinn kannst du gar nicht zunichte machen, weil die Optimierung etwas ist, was einmal getan werden muss, während der Code ständig wieder aufgerufen wird.
Natürlich kommt weiterhin hinzu, dass die Hotspot VM (woher sie auch ihren Namen hat) nur die Hotspots so krass optimiert. Dort ist der Performance-Gewinn dann auch signifikant. Genau mit der Hotspot-VM ist Java der Performance-Durchbruch gelungen, davor konnte man es guten Gewissens als lahm bezeichnen.
Das zeigt doch, wie erfolgreich das Konzept ist und das, obwohl es noch relativ neu ist.

Wie auch immer, ich will ja gar keinen Vergleich anstellen, ob es vielleicht besser ist, als klassische Compilierung. Aber das zur Laufzeit auf Grund des Laufzeitverhaltens nochmal nach-optimiert wird, und dass es auch was bringt, kannst du schon glauben.

otze

Ui, böse. otze, hiermit verwarne ich dich offiziell, nie wieder beispielcode zu posten, der nicht vollständig und nur zur Verdeutlichung dienen soll. Ich bin außerdem ein netter Mensch und helfe dir:

snief

Und zu deinem missratenen beispiel... ich mein varum sollt ich denn 2x die funktion aufrufen? Ist das nicht total bescheuert. Ich mein sowas würd ich nie machen. Ich mein sry aber wenn du den größten deppen-code nimmst dann kanns schon sein das irgendwann java mit seinen profi-optimierungen schneller ist... ich mein ein wenig muss der coder schon noch mitdenken!

du schaust dir also lieber 5 seiten quellcode durch als in 2 zeilen präzise das problem serviert zu bekommen? solche situatonen wie ich sie heir grad gezeigt hab gibts andauernd. nur halt fast nie so offensichtlich. hier im forum wimmelts davon.

aber extra für dich noch ein writeres vertrautes beispiel:

vector<int> vec;
//...
for(std::size_t i=0;i<vec.size();++i){
//...
}

auch wenn in der for schleife an vec nichts gedreht wird, kann der compiler den wiederholten aufruf von size() unter bestimmten umständen nicht rausoptimieren. Dies ist aber implementationsabhängig:

//wenn size so implementiert ist, fliegt die funktion komplett raus:
std::size_t size(){
    return m_size;
}

//bei der implementation kann zwar der funktionsaufruf gekickt werden, die berechnung aber nicht

std::size_t size(){
    //m_begin m_end sind die start/endzeiger des feldes
    return std::distance(m_begin,m_end);
}

Walli

Manuelh87 schrieb:

Walli schrieb:

Ich habe nie bestritten, dass es Supercodes gibt, mir war nur neu, dass sie aktuellen Compiler schon damit umgehen können, obwohl Mathias Fradmann sein Buch noch nicht herausgebracht hat.

Hör ich da ironie raus? pf... keine Supercodes... als nächstes willst du mir erklärenen das es keinen Weinachtsmann gibt

Du kannst mir ja mal erzählen, was DU unter Supercodes verstehst, ich muss jedenfalls schon schmunzeln weil ich dabei an den besagten Thread erinnert werde. Und dann erklärst du mir am besten noch, warum Assembler-Code niemals so schnell sein kann wie inline und Template-Tricks.

Manuelh87

otze schrieb:

[

vector<int> vec;
//...
for(std::size_t i=0;i<vec.size();++i){
//...
}

sry aber sowas würd ich auch nie machen... zeig mir mal bitte ein "nicht offensichtliches Beispiel... ich mein du redest nur von der existenz solcher beispiele aber bis jetzt war das alles völlig klar.
Da waren ja noch die Müllbeispiele von deiner seite besser *BöseKritikMach*
Na ihr wisst schon wie ich das mein... irgendwie seh ich einfach nirgendst nen richtigen anwendungsbereich... ich mein das sind alles nur fehler im stil sonst nix.

@ Walli Ich hab doch schon bedeuert dass ich das vorschnell geschrieben habe! Ich hab eben nicht an die asm templates gedacht und inline. Aber an sonsten find ich schon das dieser code extrem gut ist (kann leider keinen link geben weil ich ned weiß wo genau das war...) immerhin viel schneller als die gewöhnliche variante (mit voller optimierung vom compiler) und ich kann mir nicht vorstellen das mann es viel besser in pure asm hinkriegt zumindest nicht mit meinem Wissen. Hab ja schon beschrieben wie die struktur ist und ich mein was will man da noch verbessern? Ich weiß nix. Und wenn du jetzt ne funktion in asm machst dann ist sie so wie sie ist... da wird nixmehr optimiert und defakto kann er keine werte in registern halten (konkretes beispiel vektoraddition) da es ja nicht so geschrieben ist aber da bei c++ die register nicht fix sind kann da unter umständen besserer gesamtcode rausschauen (mit dieser funktion die irgendwo aufgerufen wird (bzw geinlined) ) allerdings mein ich da jetzt nur asm ohne templates und so. Zum Beispiel eine Vektoraddition die von vornherein schon klar ist oder wo ein teil bekannt ist da könnte es doch sein das gleich ne ganze menge erstzt wird.. das ist doch so in der asm routine nicht möglich?? Meint ihr nochimmer das es blödsinn ist... ich kann mir das genau vorstellen... na sagt mir halt was ihr davon haltet.

Nochwas:

warum Assembler-Code niemals so schnell sein kann wie inline und Template-Tricks.

Davon rede ich ja nicht... was ich sagen will ist das die implementation von einer gut geschriebenen trickreichen C++ routine bzw ausdruck durch optimierungen von vielleicht fixen sachen die schon bekannt sind (z.b. ein vektor in der gleichung oder geschicktes sachen im register lassen) besser sein KANN als die einer asm routine da man hier ja fix sagen muss welche register man verwendet und wie soller er das optimiertn?? (templates ausgenommen)

Früher wollt ich auch viel mit asm optimieren aber die einzig gute möglichkeit das zu tun mit gcc ist das man eben diese template asm sachen verwendet und die sind meiner Meinung nach nicht so einfach... alles andere schlägt sich nur mit den optimierungen des compilers und wird unter umständen gar nicht so gut übersetzt weil der compiler nix damit anfangen kann....

mfg Manuelh87

Manuelh87

Optimizer schrieb:

und dass es auch was bringt, kannst du schon glauben

Kann mir das zwar nicht so gut vorstellen (wie er da die hotspots rausfindet und nicht beim suchen schon so viel verschießt) aber glauben kann ichs ja trotzdem Na wenn das echt so viel bringt...
Aber im Grunde bessert es ja nur programmierfehler aus so wie ich das sehen! Zumindest meistens...

Naja wäre klug wenn er diese hotspots schon vorher irgendwie kennzeichnet, so könnte ich mir das schon vorstellen. Das er sozusagen die kritischen stellen sucht und dann nurmehr überprüft ob das ersetzbar ist oder nicht...

mfg Manuelh87

Jester

Manuelh87 schrieb:

Kann mir das zwar nicht so gut vorstellen (wie er da die hotspots rausfindet und nicht beim suchen schon so viel verschießt)

Oh, das ist ziemlich einfach: Du läßt das Programm einfach mal laufen und zählst mal mit wie oft Du so an ner Stelle vorbeikommst. Wenn Du in ner gewissen Zeit oft genug vorbeikommst schmeißt Du den Optimierer an (kostet dann etwas Zeit) und danach läuft genau die Stelle viel schneller. Da ein Programm normalerweise 90% seiner Zeit in 10% des Codes verbringt haste auf die Art und Weise ziemlich schnell die wichtigsten Stellen gefunden.

Btw. kannst Du noch kurz erklären was asm-templates sind?

@Rest:

Bei den geposteten Beispielen, die der Compiler nicht optimieren kann, weil er nicht weiß, daß nix geändert wird hat doch die HotSpot-VM das gleiche Problem, oder? Die Java-VM kann ja auch nicht einfach einmal laufen lassen und dann sagen hat sich einmal nicht geändert, wird sich wohl nie ändern. Sie muß es auch "beweisen" und steht an der Stelle vor dem selben Problem wie ein normaler Compiler auch.

CDW

und ich kann mir nicht vorstellen das mann es viel besser in pure asm hinkriegt zumindest nicht mit meinem Wissen.

eventuell SIMD anwenden, da könnte je nach dem nochmal eine Steigerung um 50% drin sein.
ich kann mir auch nicht vorstellen dass man das hier in C++ besser hinkriegt:

Mersenne Twister Random Number Generator optimization tutorial. The author of the mersenne twister's C code runs in 258 cycles. Agner Fog's P4 SSE2 code for the mersenne twister runs in 44 cycles. My ALU code runs in 25 cycles ( 10 times faster than the author's code, and almost twice as fast as Agner's SSE2 code). Yes, you read that right, my ALU code is running faster than Agner's SSE2 code. It's because I optimized it specifically for the P4, and you can execute up to 4 ALU instructions in parallel if you do it right. I then wrote an SSE2 version that runs in 14 cycles ( 18.5 times faster than the author's code, and 3.1 times faster than Agner's SSE2 code).
http://www.old.masmforum.com/viewtopic.php?t=3565&highlight=mersenne+twister

Wenn schon Flamewar dann richtig!

sry aber sowas würd ich auch nie machen...

wenn Leute überhaupt keine Ahnung haben was der Compiler daraus macht, dann machen die noch ganz andere Dinge . Zumindest sagst Du dass die Assembly nicht fremd ist - und das beeinflüsst einen schon ganz gut, wenn man weiß dass "einfache" Datenstrukturen und Operationen in Assembly gaaanz anders aussehen.

Das mit Compilerotimierungen ist auch nichts neues - hab noch irgednwo eine CD mit Intels Compiler drauf die ist bestimmt 2-3 Jahre alt. Ich muss auch sagen dass er nicht schlecht die Mikrooptimierungen leistet - die Schleifen und das ganze Zeug, allerdingts ist der Compiler keine höhere Intelligenz und kann keine größeren Zusammenhänge erkennen. Damit meine ich es ist schön und gut dass Compiler immer besser optimieren, aber man sollte sich nicht aussschließlich darauf verlassen denn ein Compiler kann weder den falschen Algoritmus noch die falschen Datenstrukturen wegoptimieren. Und wenn die Datenstrukturen falsch gewählt wurden (bleiben wir mal bei abstraktion) dann belegen diese nicht nur (viel) mehr Speicher - je nach dem was damit gemacht wird hat es zur Folge dass verarbeitende Operationen unnötig mehr machen ( perfomance minus), mehr als nötig in den Speicher geladen wird (nochmal minus),die Strukturen nicht mehr in den Cache passen (größeres minus) und so weiter.

immerhin viel schneller als die gewöhnliche variante (mit voller optimierung vom compiler)

siehe schon oben: wenn jemand nicht wirklich weiß in was der Code übersetzt wird - wie soll er wissen welche Variante besser ist? Wenn Du meinst dass es schneller ist als "gewöhliche Variante" - es kommt wohl aber nicht jeder drauf - und nur weil es hier, in diesem Beispiel so gut geklappt hat muss es immer noch nichts heißen - vielleicht war das ja die Ausnahme schließlich wird die "gewöhnliche Variante" ja nicht in automatisch in diese optimiert

otze

Jester schrieb:

@Rest:

Bei den geposteten Beispielen, die der Compiler nicht optimieren kann, weil er nicht weiß, daß nix geändert wird hat doch die HotSpot-VM das gleiche Problem, oder? Die Java-VM kann ja auch nicht einfach einmal laufen lassen und dann sagen hat sich einmal nicht geändert, wird sich wohl nie ändern. Sie muß es auch "beweisen" und steht an der Stelle vor dem selben Problem wie ein normaler Compiler auch.

da tritt dann die zweite optimierungstechnik in kraft: dynamisches compilieren. die variable scheint konstant zu sein, also nimmt man sie einfach als konstant-bis sich der wert ändert.

Aber im Grunde bessert es ja nur programmierfehler aus so wie ich das sehen! Zumindest meistens...

ne, du siehst das teilweise falsch. Code muss lesbar sein, und wenn ich dazu 1-2 takte opfern muss, ist mir das schnuppe, macht auf heutigen pcs eh nichts mehr aus. normal bringt es auch nichts, sone lausige for schleife umzuschreiben, weil das programm dort eh nur 2-3x durchläuft. so what? wieso an stellen optimieren, wo es nichts bringt? An der richtigen stelle einen anderen Algorithmus kann tausende dieser micro optimierungen ersetzen.

Jester

otze schrieb:

Jester schrieb:

@Rest:

Bei den geposteten Beispielen, die der Compiler nicht optimieren kann, weil er nicht weiß, daß nix geändert wird hat doch die HotSpot-VM das gleiche Problem, oder? Die Java-VM kann ja auch nicht einfach einmal laufen lassen und dann sagen hat sich einmal nicht geändert, wird sich wohl nie ändern. Sie muß es auch "beweisen" und steht an der Stelle vor dem selben Problem wie ein normaler Compiler auch.

da tritt dann die zweite optimierungstechnik in kraft: dynamisches compilieren. die variable scheint konstant zu sein, also nimmt man sie einfach als konstant-bis sich der wert ändert.

Das ist mir unklar wie das funktioniert. Ich stelle also fest, der Wert ändert sich nicht. Also nehm ich mal als konstant an... was wenn er sich nun doch mal ändert? Das find ich doch nur raus, indem ich den Wert regelmäßig prüfe und genau dazu brauch ich doch den Aufruf von z.B. vector::size. Also spare ich da nix.

Oder wie genau meinst Du das?

Optimizer schrieb:

Wie auch immer, ich will ja gar keinen Vergleich anstellen, ob es vielleicht besser ist, als klassische Compilierung. Aber das zur Laufzeit auf Grund des Laufzeitverhaltens nochmal nach-optimiert wird, und dass es auch was bringt, kannst du schon glauben.

Naja, "nach-optimieren" ist zumindest bei Java nicht so ganz richtig. Angeblich optimiert der javac zur Compilezeit selbst gar nicht. Es wird da oft gesagt, dass die Hotspot-JVM nicht so gut mit einem optimierten Code arbeiten kann und diesen nochmal optimieren kann. Das soll angeblich mit unoptimiertem Code besser funktionieren. Naja, ich weiß nicht so ganz, was man davon halten soll, aber meines Wissens nach führt der javac zumindest keine klassischen Optimierungen zur Compilezeit durch. Alle Optimierungen werden von der Hotspot-JVM durchgeführt. Wobei es natürlich ein paar einfache Ausnahmen geben wird: Ersetzung von konstanten Variablen durch ihre Werte usw.!

Vielleicht ändert sich das mit der Zeit ja auch nochmal. Könnte IMHO was bringen.

otze

@jester wie das funktioniert ist mir leider nicht bekannt, bin mir aber fast sicher, dass nicht size() überprüft wird, sondern vec. wahrscheinlich machts bei nem simplen size noch nicht viel aus, aber wenn man mehrere variablen hat die alle von den veränderungen von vec abhängig sind, kann das schon was bringen

Gregor@Home schrieb:

Naja, "nach-optimieren" ist zumindest bei Java nicht so ganz richtig. Angeblich optimiert der javac zur Compilezeit selbst gar nicht. Es wird da oft gesagt, dass die Hotspot-JVM nicht so gut mit einem optimierten Code arbeiten kann und diesen nochmal optimieren kann. Das soll angeblich mit unoptimiertem Code besser funktionieren. Naja, ich weiß nicht so ganz, was man davon halten soll, aber meines Wissens nach führt der javac zumindest keine klassischen Optimierungen zur Compilezeit durch. Alle Optimierungen werden von der Hotspot-JVM durchgeführt. Wobei es natürlich ein paar einfache Ausnahmen geben wird: Ersetzung von konstanten Variablen durch ihre Werte usw.!

Vielleicht ändert sich das mit der Zeit ja auch nochmal. Könnte IMHO was bringen.

Nach dem, was ich bis jetzt gelesen habe, ist die Server-VM (die man ganz einfach mit -server startet) in der Lage, umfassende de- und recompilierungen durchzuführen (wie z.B. inlining rückgängig machen), beispielsweise für (halb-)konstante Werte. Auch interpretiert die Server VM erst einmal eine ganze Weile den Code und sammelt dabei Informationen wie z.B. Sprungverhalten. Das kann man dann vielleicht nicht nach-Optimieren nennen, aber wenn jetzt z.B. der Fall eintritt, dass sich ein scheinbar konstanter Wert nach vielen Durchläufen ändert, muss der entsprechend optimierte Code verändert werden -> und wird wohl dann möglicherweise auch auf einen neuen konstanten Wert optimiert. Bis zu dem Pfeil ist es auf jeden Fall eine gesicherte Aussage.

@Jester: Ja, ich denke, dass die VM bei solchen Optimierungen regelmäßig als konstant angenommene Werte prüfen muss. Aber das kann signifikant weniger Arbeit sein, als ein- und die selbe Berechnung n-mal mit gleichen Werten durchzuführen. Ich gehe nicht davon aus, dass jede Variable auf mögliche Konstantheit hin untersucht wird, aber wenn ich Berechnungen habe, die lange dauern, könnte es sich lohnen, die beteiligten Variablen zu untersuchen. Ein klassischer Compiler kann diese Art der Optimierung IMHO nicht so oft durchführen, weil er wissen muss, dass sich eine Variable nicht ändert. Ein JIT-Compiler kann das einfach annehmen und evtl. darauf reagieren, wenn sich doch etwas ändert.

Oder nimm zum Beispiel Programmparameter/Werte, die du einmal aus einer Datei liest. Wenn ich irgendwie Code hab, der den Wert meines Programmparameters in Berechnungen nutzt, dann kann ich mit einem JIT-Compiler nachsehen, welchen Wert er hat und den Wert in alle Berechnungen inlinen. Bei

static final int foobar = readFromFile();

Sind Änderungen hier wohl unwahrscheinlich, da fällt dann sogar die Prüfung flach.
Inlining von Funktionsaufrufen ist vielleicht auch so ein Punkt, könnte man von Hand aber auch durchführen. Zu viel zu inlinen ist bekanntlich auch ungesund, die Hotspots intensiver zu inlinen ist wohl meistens das bessere.

Ob es das so wahnsinnig bringt, anstatt klassisch gut zu optimieren, weiß ich auch nicht. Aber diese Hotspot-Optimierung hat Java definitiv einen ordentlichen Schub gegeben. Interessant ist allerdings auch, dass Microsoft mit .Net anscheinend nicht so darauf setzt.

Angeblich optimiert der javac zur Compilezeit selbst gar nicht.

Die statischen Optimierungen macht auch der JIT-Compiler, beispielsweise das Vertauschen der Reihenfolge von Berechnungen, um schneller wieder ein Register frei zu kriegen. Ist vielleicht auch nicht unvernünftig, da es dann mehr egal ist, wenn ich meinen Code vom Eclipse Compiler generieren lasse.
Auch das ist bei .Net scheinbar wieder anders, da scheint der statische Compiler bei aktiviertem Schalter schon einiges zu optimieren. Ich bin ja sowieso gespannt, wie hier das Rennen ausgeht, Sun hat ja da doch einige Zeit erstmal verpennt, wie ich finde. Lustigerweise hat Microsoft als erstes auf JIT-Compilierung bei der Java VM gesetzt, während die Sun VM noch interpretiert hat.