Wie kann das wahrscheinlich/unwahrscheinlich-Makros in Linux-kernel arbeiten, und was ist Ihr nutzen?

Let ' s dekompilieren um zu sehen, was der GCC 4.8 mit ihm macht

Ohne __builtin_expect

#include "stdio.h"
#include "time.h"

int main() {
    /* Use time to prevent it from being optimized away. */
    int i = !time(NULL);
    if (i)
        printf("%d\n", i);
    puts("a");
    return 0;
}

Kompilieren und dekompilieren mit GCC 4.8.2 x86_64-Linux:

gcc -c -O3 -std=gnu11 main.c
objdump -dr main.o

Ausgabe:

0000000000000000 <main>:
   0:       48 83 ec 08             sub    $0x8,%rsp
   4:       31 ff                   xor    %edi,%edi
   6:       e8 00 00 00 00          callq  b <main+0xb>
                    7: R_X86_64_PC32        time-0x4
   b:       48 85 c0                test   %rax,%rax
   e:       75 14                   jne    24 <main+0x24>
  10:       ba 01 00 00 00          mov    $0x1,%edx
  15:       be 00 00 00 00          mov    $0x0,%esi
                    16: R_X86_64_32 .rodata.str1.1
  1a:       bf 01 00 00 00          mov    $0x1,%edi
  1f:       e8 00 00 00 00          callq  24 <main+0x24>
                    20: R_X86_64_PC32       __printf_chk-0x4
  24:       bf 00 00 00 00          mov    $0x0,%edi
                    25: R_X86_64_32 .rodata.str1.1+0x4
  29:       e8 00 00 00 00          callq  2e <main+0x2e>
                    2a: R_X86_64_PC32       puts-0x4
  2e:       31 c0                   xor    %eax,%eax
  30:       48 83 c4 08             add    $0x8,%rsp
  34:       c3                      retq

Den Unterricht, um in Erinnerung blieb unverändert: die ersten printf und dann puts und die retq zurück.

Mit __builtin_expect

Nun ersetzen if (i) mit:

if (__builtin_expect(i, 0))

und wir erhalten:

0000000000000000 <main>:
   0:       48 83 ec 08             sub    $0x8,%rsp
   4:       31 ff                   xor    %edi,%edi
   6:       e8 00 00 00 00          callq  b <main+0xb>
                    7: R_X86_64_PC32        time-0x4
   b:       48 85 c0                test   %rax,%rax
   e:       74 11                   je     21 <main+0x21>
  10:       bf 00 00 00 00          mov    $0x0,%edi
                    11: R_X86_64_32 .rodata.str1.1+0x4
  15:       e8 00 00 00 00          callq  1a <main+0x1a>
                    16: R_X86_64_PC32       puts-0x4
  1a:       31 c0                   xor    %eax,%eax
  1c:       48 83 c4 08             add    $0x8,%rsp
  20:       c3                      retq
  21:       ba 01 00 00 00          mov    $0x1,%edx
  26:       be 00 00 00 00          mov    $0x0,%esi
                    27: R_X86_64_32 .rodata.str1.1
  2b:       bf 01 00 00 00          mov    $0x1,%edi
  30:       e8 00 00 00 00          callq  35 <main+0x35>
                    31: R_X86_64_PC32       __printf_chk-0x4
  35:       eb d9                   jmp    10 <main+0x10>

Den printf (kompiliert __printf_chk) wurde verschoben, um das Ende der Funktion, nach puts und die Rendite zu verbessern, branch prediction wie erwähnt von anderen Antworten.

Also es ist im Grunde das gleiche wie:

int i = !time(NULL);
if (i)
    goto printf;
puts:
puts("a");
return 0;
printf:
printf("%d\n", i);
goto puts;

Diese Optimierung war nicht mit -O0.

Aber viel Glück, auf das schreiben ein Beispiel, die schneller ausgeführt wird mit __builtin_expect als ohne, CPUs sind wirklich smart diese Tage. Meine naive versuche hier.

Verursachen Sie der compiler wieder den entsprechenden Zweig Hinweise, wo die hardware Sie unterstützt. Diese Regel bedeutet nur, drehte ein paar bits in the instruction opcode, also code-Größe nicht ändern. Die CPU wird beim starten abrufen von Anweisungen aus der vorhergesagten Position und Spülen Sie die Rohrleitung und von vorn beginnen, wenn sich das als falsch herausstellt, wenn die Branche erreicht ist; in dem Fall, wo der Hinweis korrekt ist, wird der Zweig sehr viel schneller - genau wie viel schneller wird, hängt von der hardware und wie viel dies wirkt sich auf die Leistung des Codes wird davon abhängen, welchen Anteil der Zeit, die Tipp richtig ist.

Beispielsweise auf einer PowerPC-CPU ein unhinted Zweig nehmen könnte, 16 Zyklen, ein richtig angedeutet, eine 8 und eine falsch deutete eine 24. In innersten Schleifen gutes hinting kann einen gewaltigen Unterschied machen.

Portabilität ist nicht wirklich ein Problem - vermutlich die definition ist in einer pro-Plattform-header; Sie können einfach definieren, "wahrscheinlich" und "unwahrscheinlich" nichts für Plattformen, die keine Unterstützung für statische Zweig-Tipps.

(allgemein Kommentar andere Antworten decken die details)

Gibt es keinen Grund, dass Sie sollten verlieren Portabilität durch die Verwendung von Ihnen.

Haben Sie immer die option zum erstellen eines einfachen null-Effekt "inline" oder ein makro, das Ihnen erlaubt, zu kompilieren auf anderen Plattformen mit anderen Compilern.

Sie nicht nur die Vorteile der Optimierung, wenn Sie auf anderen Plattformen.

In vielen linux-Version, finden Sie complier.h in /usr/linux/, Sie können es für Gebrauch einfach. Und eine andere Meinung, unwahrscheinlich() eher nützlich eher als wahrscheinlich (ist), weil

if ( likely( ... ) ) {
     doSomething();
}

optimiert werden kann als auch in vielen compiler.

Und durch die Art und Weise, wenn Sie wollen, beachten Sie die detail-Verhalten des Codes, die Sie tun können, einfach wie folgt:

gcc -c test.c
objdump -d test.o > obj.s

Öffnen Sie dann obj.s, finden Sie die Antwort.

Diese sind GCC-Funktionen für den Programmierer zu geben, einen Hinweis an den compiler, was die wahrscheinlichste Verzweigung Bedingung in einer bestimmten Ausdruck. Dies ermöglicht dem compiler die branch-Instruktionen so, dass der häufigste Fall nimmt die geringste Anzahl von Anweisungen ausführen.

Wie der Zweig Anweisungen gebaut werden, sind abhängig von der Prozessor-Architektur.