ich habe da eine kleine Frage and die Experten. Ich stelle sie nur aus Neugier.
Welche Abfrage ist im folgenden Fall schneller:

Gegeben sei die Zahl x im Bereich [0, Integer-Maximum] (oder ist Integer-Maximum nicht im Bereich enthalten? Also [0, Integer-Maximum[ )
Also x ist ein unsigned int.

Hier zwei Abfragen - Welche ist performanter/schneller:

if(x < 2){
...
}

if(x == 0 || x == 1){ //aus Versehen &&. Naja
...
}

Danke für eure Hilfe im Voraus

Die zweite ist Unsinn.

Hoppla, sollte || sein.

Falls du if(x == 0 || x == 1) meinen solltest: Im Zweifelsfall ausprobieren, mit realen Daten. Vergleiche auf 0 können minimal schneller sein als andere. Wenn nun sehr oft 0 vorkommt, kann dies eventuell die erhöhte Codekomplexität ausgleichen.

Wenn die beiden Bedingungen äquivalent sind, und das scheint bei unsiged der Fall zu sein, wird dir da jeder halbwegs aktuelle Compiler den selben optimalen Maschinencode draus erzeugen.

Bezweifle ich. Dies ist keine triviale Umformung wie von Division zu Shiftoperator, sondern eine Mikrooptimierung deren Wirksamkeit oder Unwirksamkeit (oder gar Schädlichkeit) entscheidend von vielen Details abhängt, die der Compiler nicht kennen kann.

TNA schrieb:

Wenn die beiden Bedingungen äquivalent sind, und das scheint bei unsiged der Fall zu sein, wird dir da jeder halbwegs aktuelle Compiler den selben optimalen Maschinencode draus erzeugen.

Bezweifle ich. Dies ist keine triviale Umformung wie von Division zu Shiftoperator, sondern eine Mikrooptimierung deren Wirksamkeit oder Unwirksamkeit (oder gar Schädlichkeit) entscheidend von vielen Details abhängt, die der Compiler nicht kennen kann.

Also meiner Erfahrung nach optimieren Compiler sehr viel komplexere Sachen insbesondere bei Logik ausdrücken. x < 2 sollte auch bei allen mir bekannten Architekturen mit einem Maschinenbefehl abbildbar sein. was soll man da noch besser machen können?

Also meiner Erfahrung nach optimieren Compiler sehr viel komplexere Sachen insbesondere bei Logik ausdrücken. x < 2 sollte auch bei allen mir bekannten Architekturen mit einem Maschinenbefehl abbildbar sein. was soll man da noch besser machen können?

Tatsache. Der GCC 4.8 macht beides zu einem Vergleich auf < 2.

edit: Bei genaueren Tests kommt es auch noch da drauf an, wie die Schleife genau abgerollt wird. Manchmal kommt dann < 2, manchmal > 1.

000000013F91170C  cmp         eax,2  
000000013F91170F  jae         main+36h (013F911716h)

vs.

000000013F91172D  cmp         eax,1  
000000013F911730  ja          main+57h (013F911737h)

Ich dachte eigentlich daran, ob die eine Abfrage mehr Taktzyklen beansprucht als die andere, ohne Optimierung des Compilers. Also so wie es da steht direkt als Assembler.

Ich dachte eigentlich daran, ob die eine Abfrage mehr Taktzyklen beansprucht als die andere, ohne Optimierung des Compilers. Also so wie es da steht direkt als Assembler.

Unwahrscheinlich dass das zweite schneller ist, aber theoretisch vorstellbar. Wird, wie schon gesagt, stark von den Eingabedaten abhängen.

Also so wie es da steht direkt als Assembler.

Kommt natürlich auf die Architektur an. In der Regel sind alle Vergleisoperationen gleich schnell und die zweite Variante würde bei einer 1:1 Abbildung mindestens zwei statt einem benötigen, wovon der zweite aber je nach Fall ausgelassen werden könnte. Also je nach Eingabedaten bestenfalls gleichschnell.

Die Lehre aus diesem Fall ist aber ohnehin: Schreib verständlichen, problemnahen Code und las den Compiler machen. Der weiß im Zweifelsfall besser als du (und ich), was schneller ist.

Was ist schneller, ein "branch taken" oder ein "branch not taken"?
Also sollte man bedingte Sprungbefehle so schreiben dass meistens gesprungen wird, oder so dass meistens nicht gesprungen wird?

Wenn die Branch-Prediction richtig tippt würde ich annehmen dass "nicht gesprungen" schneller sein müsste -- weil die ganze Pipeline dabei ohne Änderung weitermachen kann. D.h. wenn es in dem Fall überhaupt einen Unterschied macht.

Aber trifft das auch zu wenn die Branch-Prediction den Sprungbefehl noch nicht kennt?
Gibt es da ne Richtwert der bei den meisten CPUs passt?

Aber trifft das auch zu wenn die Branch-Prediction den Sprungbefehl noch nicht kennt?

Andererseits ist diese Mikro-Optimierung gerade an dieser Stelle dann mit großer Wahrscheinlichkeit auch irrelevant.

Weil wir grad dabei sind...

Was ist schneller, ein "branch taken" oder ein "branch not taken"?
Also sollte man bedingte Sprungbefehle so schreiben dass meistens gesprungen wird, oder so dass meistens nicht gesprungen wird?

Wenn die Branch-Prediction richtig tippt würde ich annehmen dass "nicht gesprungen" schneller sein müsste -- weil die ganze Pipeline dabei ohne Änderung weitermachen kann. D.h. wenn es in dem Fall überhaupt einen Unterschied macht.

Aber trifft das auch zu wenn die Branch-Prediction den Sprungbefehl noch nicht kennt?
Gibt es da ne Richtwert der bei den meisten CPUs passt?

Das ist ein komplexes Thema. Zuerst muss man hier zwischen "Branch taken" im C++ Code und im daraus generierten Maschienencode unterscheiden. Das muss nämlich nicht identisch sein. Der Compiler kann das in der Regel umdrehen, wenn er es für sinnvoll hält. Auf Maschienenebene ist es meistens so, dass beim ersten Durchlauf, also praktisch immer außerhalb von Schleifen, vom "Branch not taken" Fall ausgegangen wird. Es gibt aber Architekturen wie z.B. beim PowerPC bei dem man in den Branchinstruktionen angeben kann, welcher Fall warscheilicher ist. Dafür muss der Compiler natürlich entscheiden, welchen Fall er für warscheinlicher hält. Compiler haben aber darüber hinaus oft noch Möglichkeiten schon auf höherer, maschinenunabhängiger Ebene, Optimierung zu machen, die einen der beiden Pfade bevorzugen. Oft kann der Compiler schon recht gut aus dem Programm erkennen, Welcher Pfad wahrscheinlicher ist. Manchmal allerdings auch nicht. Bei GCC schein es tatsächlich so zu sein, das er zumindest bei if ohne Else, den if-Fall für unwarscheinlicher hält. Aber auch dem kann man das mit __builtin_expect vorschreiben, wenn man sich für schlauer als der Compiler hält.

Optimieren kann man in kleinen Schleifen nur fürs erste Auftauchen, wenn die Sprungvorhersagetabelle noch leer ist. Und natürlich für selten laufenden Code, da ist sie immer wieder leer.

Wenn ich mich recht erinnere, ist die Defaultbelegung der Sprungvorhersage dann:
Sprünge nach unten werden als unwahrscheinlich angenommen, also typischerweise der überspringbare if-zweig bevorzugt.
Sprünge nach oben werden als Wahrscheinlich angenommen, also typischerweise die bedingte Schleifenwiederholung.

Die Möglichkeit anzugeben was man für wahrscheinlicher hält ist natürlich Top. Das macht Sinn. Dumm nur dass die momentan interessanteste Architektur (=x64) es nicht kann.

@all
Mir ist auch klar dass die Unterschiede vermutlich nicht SO krass reinhauen werden. Mich interessiert das rein "akademisch"
(Ich würde nie im Traum daran denken bei sowas von Hand zu optmieren anzufangen.)

Die Möglichkeit anzugeben was man für wahrscheinlicher hält ist natürlich Top. Das macht Sinn. Dumm nur dass die momentan interessanteste Architektur (=x64) es nicht kann.

Quelle?