Linux 内核中可能/不可能的宏如何工作以及它们的好处是什么？

Question

我一直在挖掘Linux内核的某些部分，发现了这样的调用：

if (unlikely(fd < 0))
{
    /* Do something */
}

或者

if (likely(!err))
{
    /* Do something */
}

我找到了它们的定义：

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

我知道它们是为了优化，但是它们是如何工作的？ 使用它们预计性能/尺寸会降低多少？ 至少在瓶颈代码中（当然是在用户空间中）是否值得这么麻烦（并且可能会失去可移植性）。

Answer 1

它们是编译器在分支上生成提示前缀的提示。 在 x86/x64 上，它们占用一个字节，因此每个分支最多会增加一个字节。 至于性能，它完全取决于应用程序——在大多数情况下，处理器上的分支预测器现在会忽略它们。

编辑：忘记了他们真正可以提供帮助的一个地方。 它可以允许编译器对控制流图重新排序，以减少“可能”路径所采用的分支数量。 这可以显着改进检查多个退出情况的循环。

Answer 2

这些是 GCC 函数，供程序员向编译器提示给定表达式中最可能的分支条件是什么。 这允许编译器构建分支指令，以便最常见的情况需要执行最少的指令。

分支指令的构建方式取决于处理器架构。

Answer 3

根据 Cody 的评论，这与 Linux 无关，而是对编译器的一个提示。 发生的情况取决于体系结构和编译器版本。

Linux 中的这一特殊功能在驱动程序中有些被误用。 正如 osgx 在 hot 属性的语义，块中调用的任何 hot 或 cold 函数都可以自动提示该条件是否可能。 例如，dump_stack() 被标记为 cold，因此这是多余的，

 if(unlikely(err)) {
     printk("Driver error found. %d\n", err);
     dump_stack();
 }

gcc 的未来版本可能会根据这些提示选择性地内联函数。 也有人建议它不是 boolean，而是 最有可能 等中的分数。通常，应该优先使用某种替代机制，例如 冷。 除了热路径之外，没有理由在任何地方使用它。 编译器在一种架构上执行的操作可能在另一种架构上完全不同。

Answer 4

这些宏向编译器提示分支的走向。 这些宏将扩展为 GCC 特定扩展（如果可用）。

GCC 使用这些来优化分支预测。 例如，如果您有类似以下的内容

if (unlikely(x)) {
  dosomething();
}

return x;

那么它可以将此代码重组为更像这样的内容：

if (!x) {
  return x;
}

dosomething();
return x;

这样做的好处是，当处理器第一次采用分支时，会产生很大的开销，因为它可能已经推测性加载并进一步执行代码。 当它确定要采用该分支时，它必须使该分支无效，并从分支目标开始。

大多数现代处理器现在都具有某种分支预测功能，但这仅在您之前已经经历过分支并且分支仍在分支预测缓存中时才有帮助。

在这些场景中，编译器和处理器可以使用许多其他策略。 您可以在 Wikipedia 找到有关分支预测器如何工作的更多详细信息： http://en.wikipedia.org/wiki/分支预测器

Answer 5

它们使编译器在硬件支持的情况下发出适当的分支提示。 这通常只意味着调整指令操作码中的一些位，因此代码大小不会改变。 CPU将从预测的位置开始获取指令，如果到达分支时发现错误，则刷新管道并重新开始； 在提示正确的情况下，这将使分支更快——具体快多少取决于硬件； 这对代码性能的影响程度取决于时间提示正确的比例。

例如，在 PowerPC CPU 上，未提示的分支可能需要 16 个周期，正确提示的分支可能需要 8 个周期，而错误提示的分支可能需要 24 个周期。在最里面的循环中，良好的提示可以产生巨大的差异。

可移植性并不是真正的问题 - 大概定义是在每个平台的标头中； 对于不支持静态分支提示的平台，您可以简单地将“可能”和“不可能”定义为空。

Answer 6

long __builtin_expect(long EXP, long C);

这个结构告诉编译器表达式 EXP
最有可能的值为 C。返回值为 EXP。
__builtin_expect 用于条件语句
表达。 在几乎所有情况下，它都会被用在
布尔表达式的上下文，在这种情况下它是很多
更方便地定义两个辅助宏：

#define unlikely(expr) __builtin_expect(!!(expr), 0)
#define likely(expr) __builtin_expect(!!(expr), 1)

然后可以使用这些宏，如下所示：

if (likely(a > 1))

参考

Answer 7

（一般评论 - 其他答案涵盖了细节）

您没有理由因为使用它们而失去可移植性。

您始终可以选择创建一个简单的零效果“内联”或宏，以便您可以使用其他编译器在其他平台上进行编译。

如果您使用其他平台，您将无法获得优化的好处。

Answer 8

在许多linux版本中，您都可以在 /usr/linux/ 中找到 compiler.h ，您可以将其包含起来以方便使用。 另一种观点是，unlikely() 比 likely() 更有用，因为

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

它也可以在许多编译器中进行优化。

顺便说一句，如果你想观察代码的详细行为，你可以简单地执行以下操作：

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

然后，打开 obj.s，你就可以找到答案。

Answer 9

让我们反编译看看 GCC 4.8 做了什么

没有 __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;
}

使用 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 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

中的指令顺序内存没有变化：首先是 printf，然后是 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 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>

printf （编译为 __printf_chk) 被移动到函数的最后，在 puts 和返回之后，以改进分支预测，如其他答案所述。

所以它基本上与：

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

此优化不是用-O0完成的。

但祝你好运，编写一个使用 __builtin_expect 比不使用 __builtin_expect 运行速度更快的示例，现在的 CPU 真的很智能。 我天真的尝试在这里。

C++20 [[likely]] 和 [[unlikely]]

C++20 已标准化这些 C++ 内置函数：如何在中使用 C++20 的 likely/unlikely 属性if-else 语句 他们很可能（双关语！）做同样的事情。

Answer 10

它们提示编译器发出指令，这些指令将导致分支预测有利于跳转指令的“可能”一侧。 这可能是一个巨大的胜利，如果预测正确，则意味着跳转指令基本上是免费的并且将占用零周期。 另一方面，如果预测错误，则意味着需要刷新处理器管道，并且可能会花费几个周期。 只要预测在大多数情况下都是正确的，这往往有利于性能。

与所有此类性能优化一样，您应该只在进行广泛的分析后才进行此操作，以确保代码确实处于瓶颈，并且可能考虑到它在紧密循环中运行的微观性质。 一般来说，Linux 开发人员都非常有经验，所以我想他们会这样做。 他们并不太关心可移植性，因为他们只针对 gcc，并且他们对想要生成的程序集有非常详细的了解。

---

请注意，除了某些 ISA 上的静态预测（向后采取/向前不采取）之外，大多数 ISA 没有办法让机器代码实际提示硬件分支预测器。 在 2013 年左右的 x86 等现代实现中，即使这不再是问题了：

• 这些年英特尔为何改变静态分支预测机制？
• 是否可以告诉分支预测器跟随该分支的可能性有多大？（关于大多数 ISA 都没有）

likely 和 unlikely 宏或 C++ [[likely]] / [[unlikely]] 注释可以提示编译器的分支布局有利于快速路径的 I-cache 局部性，并最小化快速路径上采用的分支。 还暗示在可能的情况下做出分支汇编与无分支汇编的决定。