Portable Branch Prädiktion Hinweise

Question

Gibt es irgendwelche tragbaren Weg, Verzweigungsvorhersage Hinweise zu tun? Betrachten Sie das folgende Beispiel:

if (unlikely_condition) { 
    /* ..A.. */ 
    } else { 
    /* ..B.. */ 
    } 

Ist das anders als zu tun:

if (!unlikely_condition) { 
    /* ..B.. */ 
    } else { 
    /* ..A.. */ 
    } 

Oder ist der einzige Weg, Compiler spezifische Hinweise zu benutzen? (z. B. __builtin_expect auf GCC)

Werden Compiler die if Bedingungen anders auf der Grundlage der Reihenfolge der Bedingungen behandeln?

Answer 1

Die kanonische Weise statische Verzweigungsvorhersage zu tun ist, dass if wird vorhergesagt, nicht-verzweigte (dh jede if Klausel ausgeführt wird, nicht else) und Schleifen und Rückwärts- goto s sind genommen. Geben Sie also nicht den gemeinsamen Fall in else ein, wenn Sie erwarten, dass die statische Vorhersage signifikant ist. Es ist nicht so einfach, sich in einer noch nicht erreichten Schleife fortzubewegen. Ich habe es nie ausprobiert, aber ich nehme an, es sollte ziemlich gut funktionieren, wenn man es in eine else-Klausel steckt.

Viele Compiler unterstützen irgendeine Form von #pragma unroll, aber es wird immer noch notwendig sein, es mit einer Art von #if zu schützen, um andere Compiler zu schützen.

Branch Prädiktion Hinweise können theoretisch eine vollständige Beschreibung, wie ein Flow-Control-Diagramm eines Programms zu transformieren und die grundlegenden Blöcke in ausführbaren Speicher anzuordnen Ausdruck ... so gibt es eine Vielzahl von Dingen auszudrücken, und die meisten werden nicht sehr portabel sein .

Wie von GNU in der Dokumentation für __builtin_expect empfohlen, ist die profilgeführte Optimierung den Hinweisen überlegen und mit weniger Aufwand.

Answer 2

Seien Sie einfach konsistent mit dem, was Sie tun. Ich mag es zu verwenden

if (!(someExpression)) 

Aber der Compiler sollte dies gleichermaßen behandeln.

Answer 3

Optimierung ist inhärent eine Compiler-Sache, so müssen Sie Compiler-Funktionalität verwenden, um es zu helfen. Die Sprache selbst interessiert sich nicht für Optimierungen.

Also das Beste, was Sie tun können ohne Compiler-spezifische Erweiterungen ist organisieren Sie Ihren Code in einer Weise, wo Ihre Compiler "das Richtige tun" ohne Hilfe. Aber wenn Sie sicher sein wollen, tippen Sie auf Compiler-Erweiterungen. (Sie könnten versuchen, sie hinter dem Vorprozessor abstrahiert, so dass Ihr Code tragbar bleibt.)

Answer 4

In den meisten Fällen der folgende Code

if (a) 
{ 
    ... 
} 
else 
{ 
    ... 
} 

ist eigentlich

evaluate(A) 

if (!A) 
{ 
    jmp p1 
} 

... code A 

    jmp p2 

p1: 

... code !A 

p2: 

Beachten Sie, dass, wenn A wahr ist, "Code A" ist bereits in der Pipeline. Der Prozessor sieht den Befehl "jmp p2" voraus und lädt p2-Code in die Pipeline.

Wenn A falsch ist, befindet sich der "Code! A" möglicherweise nicht in der Pipeline, daher kann er langsamer sein.

Schlussfolgerungen:

1. tun, wenn (X), wenn X als wahrscheinlicher ist, X
2. Versuch A so früh wie möglich zu bewerten, so dass die CPU dynmically die Pipeline optimieren!.

:

evaluate(A) 

do more stuff 

if (A) 
    ... 

Answer 5

Was für einen bestimmten Compiler über #ifdef mit der Überprüfung falsch ist und diese Dinge hinter einem benutzerdefinierten Makro versteckt? Sie können #define es auf den einfachen Ausdruck erweitern, wenn Sie keinen Compiler haben, der diese Optimierungshinweise unterstützt. Ich habe kürzlich etwas Ähnliches mit expliziten Cache-Vorabholungen gemacht, die GCC über eine intrinsische Funktion unterstützt.