Speed

Hallo,
ich bin Anfänger und wüsste gern, ob es zwischen den beiden Codeschnipseln Geschwindigkeitsunterschiede gibt, oder ob der Compiler das an sich überflüssige else wegoptimiert.

if (t == 2)
    return 1;
else 
    return -1;

oder

if (t == 2)
    return 1;
return -1;

Bashar

Ein naiver Compiler ohne Optimierung würde wahrscheinlich hinter das return im then-Zweig noch einen Jump nach den else-Zweig generieren, der sich natürlich nicht auf die Geschwindigkeit auswirken würde, nur auf die Codegröße. Bei realen Compilern dürfte in beiden Fällen exakt der gleiche Code generiert werden.

Ingo aka Desert Hawk

Jupp, ich denke auch, dass ein realer Compiler den gleichen Code erzeugen würde und dass beide Teile auch nicht optimiert gleich schnell laufen.
Nur noch mal zum besseren Verständnis mal kurz aufgelistet, wie das exemplarisch evtl. nicht optimiert in Assembler umgesetzt werden könnte:

IF:
Berechne t - 2
war das ergebnis != 0 springe zum Marker ELSE
    setze Rückgabewert auf 1
    verlasse Routine (return from subroutine)
    springe zum Marker ENDIF
ELSE:
    setze Rückgabewert auf -1
    verlasse Routine (return from subroutine)
ENDIF:

IF:
Berechne t - 2
war das ergebnis != 0 springe zum Marker ENDIF
    setze Rückgabewert auf 1
    verlasse Routine (return from subroutine)
ENDIF:
    setze Rückgabewert auf -1
    verlasse Routine (return from subroutine)

(Die Marker werden später nach dem Codieren in den Maschinen Code durch Adressen ersetzt)

KlausB

Hallo

ganz einfach

Testen (vorher alle Codeoptimierungen raus)
so ca. 1 Million mal durchlaufen
Zeit messen

MfG
Klaus

volkard

KlausB schrieb:

Hallo

ganz einfach

Testen (vorher alle Codeoptimierungen raus)
so ca. 1 Million mal durchlaufen
Zeit messen

MfG
Klaus

bloß einmal messen ist besser, oder?

groovemaster

Wieso schreibst du nicht einfach

return t == 2 ? 1 : -1;

Dann brauchst du dir keine Gedanken mehr machen, welche if Version schneller ist.

Windalf

@grovemaster2002
ein zeichen weniger :p

return t-2?-1:1;

Wow, nochmal ein Stück mehr optimiert.

peterchen

bloß einmal messen ist besser, oder?

Zeit messen ist ehz Voodoo geworden... bei so einer kleinen Sequenz würd' ich es mir sparen, da der Zeitbedarf viel zu stark von der "Umgebung" beeinflußt wird.

rüdiger

jo, da zu messen ist eh schwachsinn. Solche Micro "Optimierung" lohnt ja nicht.

Wenn müsste man aber doch mehrfach messen und den Mittelwert nehmen, da man ja Cache Effekte und ggf. einschreiten des Schedulers berücksichtigen muss.

Zum messen kann man aber gut rdtsc nehmen, da man damit ja jeden Takt bemerkt.

peterchen

Wenn ich mir Agner Fogs empfohlene Routine für reproduzierbare Zeiten mit RDTSC ansehe...

Zu Cache und Scheduler kommen noch die Pipelines und Pipeline-Abhängigkeiten dazu, und die drei zusammen sind ja mittlerweile so fett, daß man für Sequenzen kleiner als ein paar dutzend Opcodes gar keine Zeiten mehr zu messen braucht.

Um den Scheduler "rauszurechnen", kann man auf WinNT-Systemen zu "GetThreadTimes" greifen. Ist immerhin ein Anfang.

Ansonsten ist RDTSC natürlich hübsch

SirLant

Im C++ Forum war vor einiger Zeit doch ein Thread wo es um die Geschwindigkeit einiger
verschiedener Bedingungsblöcke ging und da war der Trinäre Operator sogar langsamer
als das äquvalente if-else.

Das muss dann IMHO ein sehr dummer Compiler gewesen sein.

rüdiger

argh, warum legen Leute eigentlich auf solche Micro Dinge so viel Wert, wo man fast garantieren kann, dass das bei jedem Compiler unterschiedlich ist, wahrscheinlich sogar bei jeder Compiler Version.

volkard

kingruedi schrieb:

argh, warum legen Leute eigentlich auf solche Micro Dinge so viel Wert, wo man fast garantieren kann, dass das bei jedem Compiler unterschiedlich ist, wahrscheinlich sogar bei jeder Compiler Version.

man stellt dabei auch sachen fest, die über compilerwchsel gleich bleiben.
übrigens sind neben
t == 2 ? 1 : -1 //if
auch mindestens
t == 2 * 2 - 1 //berechnung
und
"\xff\1"[t==2] //tabellengucker
nachguckenswert.
natürlich ist es völlig unerheblich, ob man if(t==2) return 1; else return -1; oder return t == 2 ? 1 : -1 schreibt. das sollte auch der dümmste compiler zu gleichem code backen.
manchmal in die berechnende oder tabellenguckende version zu wechslen kann durchaus gut sein. wir wissen ja alle, was ein falscher sprung kosten kann.

rüdiger

manchmal in die berechnende oder tabellenguckende version zu wechslen kann durchaus gut sein. wir wissen ja alle, was ein falscher sprung kosten kann.

ja natürlich, dass will ich auch gar nicht abstreiten.