在if语句中，GCC的__builtin_expect有什么优势？

Posted 2021-03-29

我遇到了一个#define，他们使用__builtin_expect。

The documentation说：

Built-in Function: 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:

您可以看到指令的排列顺序是bar案例在foo案例之前（而不是C代码）。这可以更好地利用CPU流水线，因为跳转会使已经取出的指令崩溃。

在执行跳转之前，它下面的指令（bar情况）被推送到管道。由于foo案例不太可能，因此不太可能跳跃，因此不大可能打破管道。

另一答案

__builtin_expect的想法是告诉编译器你通常会发现表达式的计算结果为c，这样编译器就可以针对这种情况进行优化。

我猜有人认为他们很聪明，并且他们通过这样做加快了速度。

不幸的是，除非情况得到很好的理解（可能他们没有做过这样的事情），否则可能会让事情变得更糟。文档甚至说：

一般来说，你应该更喜欢使用实际的配置文件反馈（-fprofile-arcs），因为程序员在预测他们的程序实际执行情况方面是出了名的。但是，有些应用程序难以收集此数据。

一般来说，你不应该使用__builtin_expect，除非：

• 你有一个非常真实的性能问题
• 您已经适当地优化了系统中的算法
• 您已经获得了性能数据来备份您认为特定案例最有可能的断言

另一答案

让我们反编译看看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运行速度比没有运行速度快的例子的运气好，CPUs are really smart those days。我的天真尝试are here。

另一答案

好吧，正如它在描述中所说，第一个版本在构造中添加了一个预测元素，告诉编译器x == 0分支更可能是一个 - 也就是说，它是你的程序将更频繁地使用的分支。

考虑到这一点，编译器可以优化条件，以便在预期条件成立时需要最少量的工作，代价是在意外情况下可能需要做更多的工作。

查看在编译阶段以及在生成的程序集中如何实现条件，以查看一个分支如何比另一个分支更少工作。

但是，如果有问题的条件是一个被调用很多的紧密内循环的一部分，我只希望这个优化有明显的效果，因为结果代码的差异相对较小。如果你以错误的方式优化它，你可能会降低你的表现。

另一答案

我没有看到任何解决我认为你问的问题的答案，转述：

是否有更便携的方法将分支预测提示给编译器。

你问题的标题让我想到这样做：

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

如果编译器假设'true'更有可能，那么可以优化不调用foo()。

这里的问题只是你通常不知道编译器会假设什么 - 因此任何使用这种技术的代码都需要仔细测量（如果上下文发生变化，可能需要随时监控）。