相关疑难解决方法(0)

我一直在挖掘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)

我知道它们是为了优化,但它们是如何工作的？使用它们可以预期性能/尺寸减少多少？至少在瓶颈代码中(当然在用户空间中)是否值得麻烦(并且可能失去可移植性).

我遇到了#define他们使用的一个__builtin_expect.

文件说:

内置功能: long __builtin_expect (long exp, long c)

您可以使用__builtin_expect为编译器提供分支预测信息.一般来说,你应该更喜欢使用实际的配置文件反馈(-fprofile-arcs),因为程序员在预测程序实际执行情况方面是非常糟糕的.但是,有些应用程序难以收集此数据.

返回值是值exp,它应该是一个整数表达式.内置的语义是预期的 exp == c.例如:

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

Run Code Online (Sandbox Code Playgroud)

表示我们不打算打电话foo,因为我们预计x会为零.

那么为什么不直接使用:

if (x)
    foo ();

而不是复杂的语法__builtin_expect？

对于英特尔架构,是否有一种方法可以指示GCC编译器生成的代码总是强制分支预测在我的代码中采用特定方式？英特尔硬件是否支持此功能？那么其他编译器或硬件呢？

我会在C++代码中使用它,我知道我希望快速运行的情况,并且不关心当另一个分支需要被采取时,即使它最近采用了该分支.

for (;;) {
  if (normal) { // How to tell compiler to always branch predict true value?
    doSomethingNormal();
  } else {
    exceptionalCase();
  }
}

作为Evdzhan Mustafa的后续问题,该提示是否可以在处理器第一次遇到指令时指定一个提示,所有后续的分支预测都能正常运行？

为了说清楚,我不打算在这里使用任何类型的便携性,所以任何将我绑定到某个盒子的解决方案都可以.

基本上,我有一个if语句将99%的时间评估为true,并且我试图剔除每个性能的最后一个时钟,我可以发出某种编译器命令(使用GCC 4.1.2和x86 ISA,如果告诉分支预测器它应该缓存该分支吗？

当试图理解汇编(启用编译器优化)时,我看到这种行为:

这样一个非常基本的循环

outside_loop;
while (condition) {
     statements;
}

经常被编译成(伪代码)

    ; outside_loop
    jmp loop_condition    ; unconditional
loop_start:
    loop_statements
loop_condition:
    condition_check
    jmp_if_true loop_start
    ; outside_loop

但是,如果未打开优化,则会编译为通常可理解的代码:

loop_condition:
    condition_check
    jmp_if_false loop_end
    loop_statements
    jmp loop_condition  ; unconditional
loop_end:

根据我的理解,编译后的代码更像是这样的:

goto condition;
do {
    statements;
    condition:
}
while (condition_check);

我看不到巨大的性能提升或代码可读性提升,为什么经常出现这种情况呢？是否有此循环样式的名称,例如"尾随条件检查"？

C ++ 20引入的属性[[likely]]和[[unlikely]]该语言，其可以被用于允许编译器优化为的情况下一个执行路径或者多更容易或远小于可能比其他的。

考虑到错误分支预测的成本，这似乎是一个在代码的性能关键部分可能非常有用的功能，但我不知道它实际上会导致编译器做什么。

是否有一段简单的代码可以添加[[likely]]和[[unlikely]]属性更改编译器的程序集输出？也许更重要的是，这些变化有什么作用？

我为自己的理解创建了一个简单的示例，以查看程序集是否有任何差异，但似乎这个示例太简单了，无法实际显示对程序集的任何更改：

void true_path();
void false_path();

void foo(int i) {
    if(i) {
        true_path();
    } else {
        false_path();
    }
}
void bar(int i) {
    if(i) [[likely]] {
        true_path();
    } else [[unlikely]] {
        false_path();
    }
}

在此处查看已编译的程序集。

这个问题是关于C++ 20的[[likely]]/ [[unlikely]]功能,而不是编译器定义的宏.

这个文档(cppreference)只给出了一个将它们应用于switch-case语句的例子.这个switch-case示例与我的编译器完美编译(g ++ - 7.2),所以我假设编译器已经实现了这个功能,尽管它还没有在当前的C++标准中正式引入.

但是当我像这样使用它们时if (condition) [[likely]] { ... } else { ... },我收到了一个警告:

"警告:语句开头的属性被忽略[-Wattributes]".

那么我应该如何在if-else语句中使用这些属性呢？

在谈论ifs的表现时,我们通常会谈论错误预测如何阻止管道.我看到的推荐解决方案是:

1. 相信通常有一个结果的条件的分支预测器; 要么
2. 如果合理可能的话,避免使用一点点魔法分支; 要么
3. 有条件的移动尽可能.

我找不到的是我们是否能尽早计算出病情,以便在可能的情况下提供帮助.所以,而不是:

... work
if (a > b) {
    ... more work
}

做这样的事情:

bool aGreaterThanB = a > b;
... work
if (aGreaterThanB) {
    ... more work
}

这样的事情可能会完全避免这个条件的停顿(取决于管道的长度和我们可以放在bool和if之间的工作量)？这并不一定是因为我写的,但有什么办法,以评估条件语句早,所以CPU不必尝试和预测的分支？

此外,如果这有帮助,编译器可能会做什么呢？

这是我第二次提出这个问题; 有人第一次回复,但我花了太长时间回复他们,因此没有得到充分的理解.

我要做的是了解更多关于现代架构的指令部分; 我假设所有指令都由分支预测器预测,用于指令获取单元按预测获取.

试图帮助提及"分支指令"的另一位绅士也与预测的指令一起发送.该"分支指令"测试分支预测器的预测条件是否正确.我还假设这些分支指令转到分支执行单元,DONT需要来自内存的任何加载.

我不明白的是:

• 分支执行单元如何通过该指令知道猜测是否正确？
• 一旦知道它是正确的,会发生什么？
• 是否每次预测都会发出分支指令(基本上意味着...每次预测都会发生？)
• 分支预测必须在预测指令之前或之后进行吗？
• 分支指令是否需要从内存中加载任何数据？如果是这样,它是什么？

谢谢!

我试图详细了解当分支预测错误时，skylake CPU管道的各个阶段中的指令会发生什么，以及从正确的分支目标开始执行指令的速度如何。

因此，让我们在这里将两个代码路径标记为红色（一个预测但未实际采用）和绿色（一个已预测但未预期）。所以问题是：1.在红色指令开始被丢弃之前，分支必须经过管道多远（以及在管道的哪个阶段被丢弃）？2.绿色指令（在分支到达的流水线阶段方面）多久可以开始执行？

我看过Agner Fogg的文档和许多讲义，但这些观点并不清楚。

在 Visual Studio 中阅读标准库算法的实现时，他们根本不使用[[likely]]/属性。[[unlikely]]对我来说，应该使用的教科书示例[[unlikely]]是例如std::find_if(...)，微软已经这样实现：

// Note that some noise are removed from the code
template <class _InIt, class _Pr>
_InIt find_if(_InIt _First, const _InIt _Last, _Pr _Pred) {
    for (; _First != _Last; ++_First) {
        if (_Pred(*_First)) {
            break;
        }
    }
    return _First;
}

如前所述，find_if(...)这是 if 子句的 true 分支不太可能的教科书示例，因为大多数情况下它会在谓词验证为 true 之前迭代几个元素，因此 [[unlikely]] 将是一个优化机会。Microsoft 没有[[unlikely]]在这里使用该属性有什么原因吗？

我对分支预测了解一些。这发生在 CPU 上，与编译无关。尽管您可能能够告诉编译器一个分支是否比另一个分支更有可能，例如在 C++20 中，通过[[likely]]and [[unlikely]]（请参阅cppreference）这与 CPU 执行的分支预测是分开的（请参阅我可以使用我的代码改进分支预测吗？ ？）。

据我所知，当我有一个循环（带有退出条件）时，CPU 会预测退出条件不会得到满足，并尝试在循环内执行一些操作，即使条件尚未检查。如果 CPU 预测正确，它会节省一些时间，一切都会好起来。然而，如果它无法正确预测会发生什么？我知道这会对性能造成影响，但我不知道一些已经完成的操作是否被丢弃或逆转，或者只是如何处理。

现在我想出了两个简单的例子。第一个（如果我们忽略编译器可能只是在编译时计算总和并且我假设没有发生优化）对于 CPU 来说应该很容易预测。循环条件始终相同，并且循环中的条件仅切换一次。这意味着预测将为我们带来很好的性能提升，即使它失败了几次，添加一个数字也可以很容易地逆转。

在第二个示例中，退出条件也很容易预测。在循环体中，我int通过分配一个新数组malloc。请注意，我不是故意释放它的，因为我希望分配能够长期成功，以便 CPU 预测到这一成功。有时，当我用完内存（我没有计算总内存消耗并假设内存不会移动到磁盘）或发生其他错误时，分配会失败。这意味着ptrwill beNULL并且取消引用它是UB。没有定义会发生什么，它可能只是一个空操作，使我的程序崩溃或导致我的电脑飞走。因此我得出结论，CPU 不能简单地撤消这一点，我想知道会发生什么。

#include <stdlib.h>

#define VERSION 1

#if VERSION == 1
int main() {
    size_t sum = 0ull;

    for (size_t i = 0ull, max = 1'000ull; i < max;  ++i) {
        if (i < (max / 2)) {
            sum += 2 * i;
        } …