if elseステートメントにおけるGCCの__builtin_expectの利点は何ですか？

#define彼らが使用しているに出会いました__builtin_expect。

ドキュメントは言う：

組み込み関数： long __builtin_expect (long exp, long c)

__builtin_expectコンパイラーに分岐予測情報を提供するために使用できます。-fprofile-arcsプログラマーはプログラムが実際にどのように機能するかを予測することで悪名高いため、一般に、これには実際のプロファイルフィードバックを使用することをお勧めします（）。ただし、このデータを収集するのが難しいアプリケーションがあります。

戻り値はの値でexpあり、整数式でなければなりません。組み込みのセマンティクスは、それが期待されていること exp == cです。例えば：

      if (__builtin_expect (x, 0))
        foo ();

ゼロになることfooを期待xしているため、を呼び出すことを期待していないことを示します。

だから直接使用しないのはなぜですか：

if (x)
    foo ();

複雑な構文の代わりに__builtin_expect？

以下から生成されるアセンブリコードを想像してください。

if (__builtin_expect(x, 0)) {
    foo();
    ...
} else {
    bar();
    ...
}

私はそれが次のようなものであるべきだと思います：

  cmp   $x, 0
  jne   _foo
_bar:
  call  bar
  ...
  jmp   after_if
_foo:
  call  foo
  ...
after_if:

（Cコードではなく）barケースがケースに先行するような順序で命令が配置されていることがわかりfooます。ジャンプはすでにフェッチされた命令をスラッシュするため、これはCPUパイプラインをよりよく利用できます。

ジャンプが実行される前に、その下の命令（barケース）がパイプラインにプッシュされます。以来fooケースはほとんどありません、あまりにもジャンプすることはほとんどありません、したがって、パイプラインをスラッシングすることはほとんどありません。

逆コンパイルして、GCC 4.8がそれで何をするかを見てみましょう

Blagovestは、パイプラインを改善するためにブランチの逆転について言及しましたが、現在のコンパイラーは実際にそれを行っていますか？確認してみましょう！

なし __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)
        puts("a");
    return 0;
}

GCC 4.8.2 x86_64 Linuxでコンパイルおよび逆コンパイルします。

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

出力：

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 0a                   jne    1a <main+0x1a>
  10:       bf 00 00 00 00          mov    $0x0,%edi
                    11: R_X86_64_32 .rodata.str1.1
  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

メモリ内の命令の順序は変更されていません。最初にputs、次にretq戻ります。

と __builtin_expect

次に置き換えますif (i)：

if (__builtin_expect(i, 0))

そして私たちは得ます：

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 07                   je     17 <main+0x17>
  10:       31 c0                   xor    %eax,%eax
  12:       48 83 c4 08             add    $0x8,%rsp
  16:       c3                      retq
  17:       bf 00 00 00 00          mov    $0x0,%edi
                    18: R_X86_64_32 .rodata.str1.1
  1c:       e8 00 00 00 00          callq  21 <main+0x21>
                    1d: R_X86_64_PC32       puts-0x4
  21:       eb ed                   jmp    10 <main+0x10>

puts関数の最後に移動されたretqリターン！

新しいコードは基本的に次のものと同じです。

int i = !time(NULL);
if (i)
    goto puts;
ret:
return 0;
puts:
puts("a");
goto ret;

この最適化は、では行われていません-O0。

しかし__builtin_expect、CPUは、使用しない場合よりも速く実行される例を書くのに幸運です。当時のCPUは本当に賢いです。私の素朴な試みはここにあります。

C ++ 20 [[likely]]および[[unlikely]]

C ++ 20はこれらのC ++ビルトインを標準化しました：if-elseステートメントでC ++ 20の見込み/非見込み属性を使用する方法彼らはおそらく（駄洒落！）同じことをするでしょう。

の考え方__builtin_expectは、通常は式がcに評価されることをコンパイラに通知し、コンパイラがその場合に最適化できるようにすることです。

誰かが彼らが賢いことだと思っていて、これをすることで物事をスピードアップしていると思います。

残念ながら、状況が非常によく理解されていない限り（そのようなことを何も行っていない可能性があります）、状況が悪化した可能性があります。ドキュメンテーションは言う：

-fprofile-arcsプログラマーはプログラムが実際にどのように機能するかを予測することで悪名高いため、一般に、これには実際のプロファイルフィードバックを使用することをお勧めします（）。ただし、このデータを収集するのが難しいアプリケーションがあります。

一般に、次の場合を__builtin_expect除いて使用しないでください。

• あなたは非常に現実的なパフォーマンスの問題を抱えています
• システムのアルゴリズムをすでに適切に最適化している
• 特定のケースが最も可能性が高いという主張を裏付けるパフォーマンスデータがあります

さて、説明で述べているように、最初のバージョンは予測要素を構築に追加して、x == 0分岐がより可能性の高い分岐であることをコンパイラーに伝えます-つまり、プログラムがより頻繁に取る分岐です。

このことを念頭に置いて、コンパイラーは条件付きを最適化できるため、予期しない条件が発生した場合により多くの作業を行わなければならないという犠牲を払って、期待される条件が満たされたときに最小限の作業で済みます。

コンパイルフェーズでの条件文の実装方法と、結果のアセンブリで、1つのブランチが他のブランチよりも効率が悪い場合があるかどうかを確認します。

ただし、結果のコードの違いは比較的小さいため、問題の条件がたくさん呼び出されるタイトな内部ループの一部である場合にのみ、この最適化が顕著な効果をもたらすと期待します。また、間違った方法で最適化すると、パフォーマンスが低下する可能性があります。

言い換えると、あなたが尋ねていたと思う質問に答える答えは見当たりません。

ブランチ予測をコンパイラに示唆するよりポータブルな方法はありますか？

あなたの質問のタイトルは私にそれをこのようにすることを考えさせました：

if ( !x ) {} else foo();

コンパイラーが「true」である可能性が高いと想定する場合、を呼び出さないように最適化できfoo()ます。

ここでの問題は、一般に、コンパイラーが何を想定するかを知らないということだけです。このため、この種の手法を使用するコードは、慎重に測定する必要があります（コンテキストが変化した場合は、時間の経過とともに監視する必要があります）。

@Blagovest Buyuklievおよび@Ciroに従ってMacでテストします。アセンブルは明確に見え、コメントを追加します。

コマンドは gcc -c -O3 -std=gnu11 testOpt.c; otool -tVI testOpt.o

-O3を使用すると、__builtin_expect（i、0）が存在してもしなくても同じように見えます。

testOpt.o:
(__TEXT,__text) section
_main:
0000000000000000    pushq   %rbp     
0000000000000001    movq    %rsp, %rbp    // open function stack
0000000000000004    xorl    %edi, %edi       // set time args 0 (NULL)
0000000000000006    callq   _time      // call time(NULL)
000000000000000b    testq   %rax, %rax   // check time(NULL)  result
000000000000000e    je  0x14           //  jump 0x14 if testq result = 0， namely jump to puts
0000000000000010    xorl    %eax, %eax   //  return 0   ,  return appear first 
0000000000000012    popq    %rbp    //  return 0
0000000000000013    retq                     //  return 0
0000000000000014    leaq    0x9(%rip), %rdi  ## literal pool for: "a"  // puts  part, afterwards
000000000000001b    callq   _puts
0000000000000020    xorl    %eax, %eax
0000000000000022    popq    %rbp
0000000000000023    retq

-O2を指定してコンパイルすると、__ builtin_expect（i、0）を使用した場合と使用しない場合で外観が異なります

最初に

testOpt.o:
(__TEXT,__text) section
_main:
0000000000000000    pushq   %rbp
0000000000000001    movq    %rsp, %rbp
0000000000000004    xorl    %edi, %edi
0000000000000006    callq   _time
000000000000000b    testq   %rax, %rax
000000000000000e    jne 0x1c       //   jump to 0x1c if not zero, then return
0000000000000010    leaq    0x9(%rip), %rdi ## literal pool for: "a"   //   put part appear first ,  following   jne 0x1c
0000000000000017    callq   _puts
000000000000001c    xorl    %eax, %eax     // return part appear  afterwards
000000000000001e    popq    %rbp
000000000000001f    retq

今__builtin_expect（i、0）

testOpt.o:
(__TEXT,__text) section
_main:
0000000000000000    pushq   %rbp
0000000000000001    movq    %rsp, %rbp
0000000000000004    xorl    %edi, %edi
0000000000000006    callq   _time
000000000000000b    testq   %rax, %rax
000000000000000e    je  0x14   // jump to 0x14 if zero  then put. otherwise return 
0000000000000010    xorl    %eax, %eax   // return appear first 
0000000000000012    popq    %rbp
0000000000000013    retq
0000000000000014    leaq    0x7(%rip), %rdi ## literal pool for: "a"
000000000000001b    callq   _puts
0000000000000020    jmp 0x10

要約すると、__ builtin_expectは最後のケースで機能します。