对于英特尔架构，有没有一种方法可以指示GCC编译器在我的代码中始终强制分支预测以特定方式进行？ 英特尔硬件是否支持这样做？其他编译器或硬件呢？
我会在C ++代码中使用它，在那里我知道我希望快速运行的情况，并且不在意其他分支需要被采取时的减速，即使最近已经采取了该分支。
for (;;) {
if (normal) { // How to tell compiler to always branch predict true value?
doSomethingNormal();
} else {
exceptionalCase();
}
}
GCC支持函数__builtin_expect(long exp, long c)来提供这种功能。您可以在此处查看文档here。
其中exp是使用的条件，c是期望的值。例如，在您的情况下，您希望
if (__builtin_expect(normal, 1))
由于句法不太自然，通常可以通过定义两个自定义宏来使用。
#define likely(x) __builtin_expect (!!(x), 1)
#define unlikely(x) __builtin_expect (!!(x), 0)
只是为了简化任务。
请注意：
constexpr 函数？请说明原因。 - Columboconstexpr 函数可以取代这个宏。我相信它必须直接出现在 if 语句中。同样的原因，assert 也永远不可能是一个 constexpr 函数。 - Mooing Duckconstexpr 仅涉及值语义，而不涉及实现特定汇编代码的内联）；对代码的直接解释（无内联）是没有意义的。根本没有理由使用函数来实现这个。 - Alex Celeste__builtin_expect本身就是一种优化提示，所以认为简化其使用的方法取决于优化是不太有说服力的。 另外，我添加constexpr限定符并不是为了使其能够正常工作，而是为了使其在常量表达式中能够正常工作。同时，确实有使用函数的理由。例如，我不想用一个可爱的名称（如"likely"）来污染我的整个命名空间。我得使用诸如LIKELY这样的名称，以强调它是一个宏并避免碰撞，但这样做只会让代码变得丑陋。 - Columbogcc有 long __builtin_expect (long exp, long c)（我强调）：
您可以使用__builtin_expect为编译器提供分支预测信息。通常，最好使用实际的性能反馈来进行优化(-fprofile-arcs)，因为程序员通常不能正确地预测他们的程序的实际性能。但是，在某些情况下，很难收集这些数据。
返回值是exp的值，exp应该是一个整数表达式。内置函数的语义是预期exp == c。例如：
if (__builtin_expect (x, 0)) foo ();表示我们不希望调用foo，因为我们希望x为零。由于exp的限制只能使用整数表达式，因此您应该使用以下构造：
if (__builtin_expect (ptr != NULL, 1)) foo (*ptr);在测试指针或浮点数值时，如文档所述，您应该优先使用实际的配置文件反馈，本文显示了一个实际示例，至少在他们的情况下，这种方法最终比使用
__builtin_expect来说更加有效。另请参见如何在g++中使用基于配置文件的优化？我们还可以在Linux内核新手文章中找到关于kernal宏likely()和unlikely()使用此功能的信息：
#define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0)注意，在我们的宏中使用了
!!，可以在为什么使用 !!(condition) 而不是 (condition)?中找到其解释。仅因为这种技术在Linux内核中使用并不意味着始终有必要使用它。正如我最近回答的这个问题在将参数作为编译时常量或变量传递时函数性能的差异中所看到的，很多手动优化技术在一般情况下都不起作用。我们需要仔细地分析代码，以了解一种技术是否有效。许多旧技术甚至可能与现代编译器优化无关。
请注意，虽然内建函数不具备可移植性，但clang 也支持 __builtin_expect。
此外，在一些架构上可能没有影响。
不，没有。(至少在现代x86处理器上是这样的。)
__builtin_expect在其他回答中提到，它会影响gcc编译汇编代码的方式。但它 并不直接影响CPU的分支预测。 当然，通过重新排列代码，会对分支预测产生间接影响。但在现代x86处理器上，没有一条指令告诉CPU“假设该分支被/未被执行”。
有关更多细节，请参见此问题：Intel x86 0x2E / 0x3E前缀分支预测实际使用了吗？
明确表示，__builtin_expect和/或使用-fprofile-arcs都可以通过代码布局向分支预测器提供提示(请参见x86-64汇编性能优化-对齐和分支预测)来优化代码性能，并通过将“不太可能”的代码与“可能”的代码分开，从而改善缓存行为。
__builtin_expect。所以这应该只是一条评论。但它并不是错误的，所以我取消了我的负评。 - Nemo__builtin_expect轻松创建一个测试用例，然后使用perf stat进行测量，从而产生非常高的分支错误率。它只影响分支布局。顺便说一下，自Sandybridge或至少Haswell以来，英特尔几乎没有使用静态预测；BHT中总是会有一些预测，无论它是否过时。 https://xania.org/201602/bpu-part-two - Peter Cordes在C++11中定义likely/unlikely宏的正确方法如下:
#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)
与 [[likely]] 不同，该方法适用于所有 C++ 版本，但依赖于非标准扩展 __builtin_expect。
当这些宏以此方式定义时：
#define LIKELY(condition) __builtin_expect(!!(condition), 1)
那可能改变if语句的含义并破坏代码。请考虑以下代码：
#include <iostream>
struct A
{
explicit operator bool() const { return true; }
operator int() const { return 0; }
};
#define LIKELY(condition) __builtin_expect((condition), 1)
int main() {
A a;
if(a)
std::cout << "if(a) is true\n";
if(LIKELY(a))
std::cout << "if(LIKELY(a)) is true\n";
else
std::cout << "if(LIKELY(a)) is false\n";
}
它的输出：
if(a) is true
if(LIKELY(a)) is false
如您所见，使用!!作为bool转换的定义破坏了if语句的语义。
这里的重点不是operator int()和operator bool()应该有关联。这是良好的实践。
而是使用!!(x)而非static_cast<bool>(x)会丢失关于C++11 上下文转换的上下文。
switch中涉及的上下文转换，你提出了一个有趣的观察，谢谢。这里涉及到的上下文转换是特定于类型bool和列出的五个特定上下文的上下文转换，但不包括switch上下文。 - Maxim Egorushkin(condition)，而没有使用!!(condition)。在更改后，两者都是true（使用g++ 7.1测试）。你能否构造一个实际演示当你使用!!进行布尔化时所讨论的问题的例子？ - Peter Cordesoperator!就可以了 :P - Peter Cordes__builtin_expect来向编译器提供关于如何排列汇编代码的提示。正如官方文档所指出的，在大多数情况下，您脑中内置的汇编器不会像GCC团队精心制作的汇编器那样好。最好使用实际的配置文件数据来优化代码，而不是猜测。noinline和cold属性，它们恰好执行它们听起来要做的事情。这些属性只能应用于函数，但是在C++11中，您可以声明内联lambda函数，并且这两个属性也可以应用于lambda函数。__builtin_expect更普遍有用。几乎没有x86处理器的任何一代使用分支预测提示(参考)，因此您唯一能够影响的就是汇编代码的顺序。由于您知道哪些是错误处理或“边缘情况”代码，因此可以使用此注释来确保编译器永远不会预测到它并且在优化大小时将其链接到“热”代码之外。void FooTheBar(void* pFoo)
{
if (pFoo == nullptr)
{
// Oh no! A null pointer is an error, but maybe this is a public-facing
// function, so we have to be prepared for anything. Yet, we don't want
// the error-handling code to fill up the instruction cache, so we will
// force it out-of-line and onto a "cold" path.
[&]() __attribute__((noinline,cold)) {
HandleError(...);
}();
}
// Do normal stuff
⋮
}
-fprofile-use编译时），GCC将自动忽略此选项并选择profile feedback。详见官方文档：https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes。__builtin_expect所做的。它并不无用。你说的cold属性也是有用的，但我认为你低估了__builtin_expect的实用性。 - Nemo从C++20开始，likely和unlikely属性应该已经被规范化并且已经在g++9中得到支持。因此如此处所讨论的那样，您可以编写
if (a > b) {
/* code you expect to run often */
[[likely]] /* last statement here */
}
例如，在以下代码中，由于if块中的[[unlikely]]，else块被内联了。
int oftendone( int a, int b );
int rarelydone( int a, int b );
int finaltrafo( int );
int divides( int number, int prime ) {
int almostreturnvalue;
if ( ( number % prime ) == 0 ) {
auto k = rarelydone( number, prime );
auto l = rarelydone( number, k );
[[unlikely]] almostreturnvalue = rarelydone( k, l );
} else {
auto a = oftendone( number, prime );
almostreturnvalue = oftendone( a, a );
}
return finaltrafo( almostreturnvalue );
}
if 中使用 [[unlikely]] 而在 else 中使用 [[likely]]？ - WilliamKF__builtin_expect可以用来告诉编译器你期望分支走哪个方向。这会影响代码的生成。典型的处理器按顺序运行代码更快。因此，如果你写：
if (__builtin_expect (x == 0, 0)) ++count;
if (__builtin_expect (y == 0, 0)) ++count;
if (__builtin_expect (z == 0, 0)) ++count;
if (x == 0) goto if1;
back1: if (y == 0) goto if2;
back2: if (z == 0) goto if3;
back3: ;
...
if1: ++count; goto back1;
if2: ++count; goto back2;
if3: ++count; goto back3;