有没有一种可移植的方法来进行分支预测提示？考虑下面的例子：
if (unlikely_condition) {
/* ..A.. */
} else {
/* ..B.. */
}
这与做下面的操作有什么不同：
if (!unlikely_condition) {
/* ..B.. */
} else {
/* ..A.. */
}
还有其他方法可以达到类似于GCC中的 __builtin_expect 这样的编译器特定提示吗？
编译器是否会根据条件的顺序不同而对 if 条件进行不同的处理？
进行静态分支预测的经典方法是将 if 预测为非分支 (即执行每个 if 子句而不是 else)，并且循环和向后跳转语句会被执行。因此，如果你希望静态预测起到重要作用，则不要将通用情况放在 else 中。解决未执行循环的问题并不容易；我从未尝试过，但我认为将其放在 else 子句中应该能够很方便地实现。
许多编译器都支持某种形式的 #pragma unroll，但仍需要用一些 #if 保护它以防止其他编译器。
分支预测提示理论上可以表达如何转换程序的控制流图并安排基本块在可执行内存中的完整描述... 因此有许多要表达的内容，大多数不太可移植。
正如 GNU 在 __builtin_expect 文档中建议的那样，基于剖面优化比提示更加优秀，并且需要的工作量更少。
在大多数情况下，以下代码
if (a)
{
...
}
else
{
...
}
实际上是
evaluate(A)
if (!A)
{
jmp p1
}
... code A
jmp p2
p1:
... code !A
p2:
注意，如果A为真，则“代码A”已经在流水线中。处理器将看到“jmp p2”命令，加载p2代码到流水线。
如果A为假，则“代码！A”可能不在流水线中，因此速度可能较慢。
结论：
:
evaluate(A)
do more stuff
if (A)
...
优化本质上是编译器的事情，因此您必须使用编译器功能来帮助它。语言本身并不关心（或强制执行）优化。
因此，在没有特定于编译器的扩展的情况下，最好的方法是以这样一种方式组织您的代码，使得您的编译器可以“自动完成正确的事情”。但如果您想确保，请使用编译器扩展。（您可以尝试在预处理器中将它们抽象化，以便您的代码保持可移植性。）
inline、restrict、register），尽管现代编译器上有些比其他一些更有意义。某个特定的实现是否真正利用这些提示并不重要：如果有合理的机会会有所作为，那么它就是一个好功能。我认为，在主体中使用静态分支预测并不符合这个标准，所以我认为不将其包含在内并不是一个坏决定。虽然这是一个评估案件的判断，但并不完全是“我们永远不关心优化”。 - Steve Jessoprestrict作为一种过早的优化可能是值得的。它不会造成任何伤害，通过防止可怕的存储/加载依赖关系，它可能会产生显着的好处，并且在适用的情况下，它很可能是一个文档要求（如memcpy），无论是否反映在源代码中。其他的（在C++03中），我同意你的“meh” :-) - Steve Jessoprestrict，因为它不是当前标准的一部分。 :) - GManNickGC++20提供likely和unlikely属性
允许编译器针对包括该语句的执行路径比不包括该语句的任何替代执行路径更或多或少可能的情况进行优化
通过#ifdef检查特定编译器有什么问题，并将这些内容隐藏在自定义宏后面？您可以将其#define扩展到普通表达式中，在没有支持这些优化提示的编译器的情况下进行。我最近使用内部函数对显式缓存预取进行了类似的操作，GCC支持此操作。
保持你所做的一致。我喜欢使用
if (!(someExpression))
但编译器应该同等对待这个。
if(likely(...))废物，我认为这真的很糟糕。首先，在英语中它不太自然——听起来像是“如果这个条件可能为真”，而不是“如果这个条件为真，那么它可能是”。另外，这只是杂乱无章的东西。除非你有大量的性能关键条件语句无法编译到cmov或类似指令，否则可以忽略分支预测提示。 - R.. GitHub STOP HELPING ICEif(unlikely(...))。他们更喜欢早期退出，使代码流程更容易跟踪。如果他们不这样做，那么静态分支预测将总是失败。 - Oskar N.