谈到ifs的性能时，通常会讨论误预测如何会使流水线停滞。我看到的推荐解决方案有：
我找不到的是我们是否可以提前计算条件以在可能的情况下帮助。所以，与其：
... work
if (a > b) {
... more work
}
像这样做：
bool aGreaterThanB = a > b;
... work
if (aGreaterThanB) {
... more work
}
像这样的代码是否有可能在条件语句中完全避免停顿（取决于流水线长度和我们可以放置在 bool 和 if 之间的工作量）？它不必像我写的那样，但是否有一种方法可以尽早评估条件语句，以便CPU不必尝试预测分支？
此外，如果有帮助的话，编译器是否有可能自行执行此操作？
<运算符）可能会出现错误预测的地方，而是后续的条件分支：毕竟，它是一个“分支”错误预测。在您的示例中，分支在两个位置都是相同的：它的形式只是从if (a > b)更改为if (aGreaterThanB)。int test1(int a, int b) {
int result = a * b;
result *= result;
if (a > b) {
return result + a;
}
return result + b * 3;
}
int test2(int a, int b) {
bool aGreaterThanB = a > b;
int result = a * b;
result *= result;
if (aGreaterThanB) {
return result + a;
}
return result + b * 3;
}
我检查了gcc、clang2和MSVC，发现它们都编译了这两个函数identically（输出在编译器之间有所不同，但对于每个编译器，这两个函数的输出是相同的）。例如，使用gcc编译test2的结果如下：
test2(int, int):
mov eax, edi
imul eax, esi
imul eax, eax
cmp edi, esi
jg .L4
lea edi, [rsi+rsi*2]
.L4:
add eax, edi
ret
cmp指令对应于a > b条件，gcc已将其移回到所有“工作”之后，并将其放在条件分支jg旁边。
因此，如果我们知道源代码中操作顺序的简单操作无效，则可以做些什么来解决问题？事实证明，您可以通过任何可以将分支条件“向上”移动到数据流图中来提高性能，从而使误判能够更早地得到解决。我不会深入探讨现代CPU如何依赖数据流，但您可以在这里找到简要概述，并在末尾找到进一步阅读的指针。
这是一个涉及链接列表遍历的实际示例。
考虑将空终止的链接列表中的所有值相加，该链接列表还将其长度1存储为列表头结构的成员。链接列表实现为一个list_head对象和零个或多个列表节点（具有单个int值负载），定义如下：
struct list_node {
int value;
list_node* next;
};
struct list_head {
int size;
list_node *first;
};
规范的搜索循环将使用node->next == nullptr在最后一个节点中的哨兵来确定已经到达列表的末尾，如下所示：
long sum_sentinel(list_head list) {
int sum = 0;
for (list_node* cur = list.first; cur; cur = cur->next) {
sum += cur->value;
}
return sum;
}
这已经是最简单的形式了。
然而，这会将结束求和的分支（即首次出现cur == null的分支）放在节点之间指针追踪的末尾，这是数据流图中最长的依赖关系。如果此分支预测错误，那么错误预测的解决将发生“晚”，前端气泡将直接增加运行时间。
另一方面，您可以通过显式计算节点来进行求和，如下所示：
long sum_counter(list_head list) {
int sum = 0;
list_node* cur = list.first;
for (int i = 0; i < list.size; cur = cur->next, i++) {
sum += cur->value;
}
return sum;
}
<sum_sentinel(list_head)>:
test rsi,rsi
je 1fe <sum_sentinel(list_head)+0x1e>
xor eax,eax
loop:
add eax,DWORD PTR [rsi]
mov rsi,QWORD PTR [rsi+0x8]
test rsi,rsi
jne loop
cdqe
ret
<sum_counter(list_head)>:
test edi,edi
jle 1d0 <sum_counter(list_head)+0x20>
xor edx,edx
xor eax,eax
loop:
add edx,0x1
add eax,DWORD PTR [rsi]
mov rsi,QWORD PTR [rsi+0x8]
cmp edi,edx
jne loop:
cdqe
ret
** Running benchmark group Tests written in C++ **
Benchmark Cycles BR_MIS
Linked-list w/ Sentinel 12.19 0.00
Linked-list w/ count 12.40 0.00
让我们将分支预测添加到其中，通过更改列表生成代码以创建平均长度为5的列表，但实际长度在[0, 10]中均匀分布。求和代码未更改：只有输入不同。随机列表长度的结果：
** Running benchmark group Tests written in C++ **
Benchmark Cycles BR_MIS
Linked-list w/ Sentinel 43.87 0.88
Linked-list w/ count 27.48 0.89
BR_MIS列显示我们每个列表几乎会出现一个分支预测错误6，这是预期的，因为循环退出是不可预测的。
然而，哨兵算法现在需要大约44个周期，而计数算法需要大约27.5个周期。计数算法快约16.5个周期。您可以玩弄列表长度和其他因素，并改变绝对时间，但差异几乎总是在16-17个周期左右，这恰好与最近英特尔的分支预测惩罚相同！通过提前解决分支条件，我们避免了前端气泡，在那里什么都不会发生。
另一个例子是像一个循环一样计算浮点值的循环，比如泰勒级数逼近，其中终止条件取决于计算出的值的某个函数。这具有与上述相同的效果：终止条件取决于缓慢的循环传递依赖项，因此解决它与解决值本身一样慢。如果退出不可预测，您将遭受停顿。
如果您可以更改为提前计算迭代次数，则可以使用脱耦的整数计数器作为终止条件，避免气泡。即使提前计算需要一些时间，它仍然可以提供整体加速（而且计算可以与循环的第一次迭代并行运行，因此它可能比您预期的成本要低得多）。
1 MIPS是一个有趣的例外，没有标志寄存器 - 测试结果直接存储在通用寄存器中。
2 Clang以无分支的方式编译了这个和许多其他变体，但它仍然很有趣，因为您仍然具有测试指令和条件移动（代替分支）的相同结构。
3 类似于C++11的std::list。
4 结果发现，在x86上，每个节点的工作实际上在两种方法之间非常相似，因为dec隐式设置了零标志，所以我们不需要额外的test指令，而指针追踪中使用的mov则不需要，因此计数器方法有一个额外的dec，而哨兵方法有一个额外的test，使其几乎相等。
5 尽管这部分只是因为gcc没有将增量for循环转换为递减循环以利用dec设置零标志，避免了cmp。也许新版本的gcc做得更好。另见注释4。
6 我想这更接近于0.9而不是1.0，因为也许分支预测器仍然会正确处理长度= 10的情况，因为一旦循环了9次，下一个迭代将总是退出。一个不那么合成/精确的分布不会表现出来。
7 我说“大多数情况”是因为在某些情况下，通过这种源代码或汇编级别的重排可能会节省一两个周期，因为这些事情可能对乱序处理器中的执行顺序产生轻微影响，执行顺序也受到汇编顺序的影响，但仅在数据流图的约束范围内。 请参见这个评论。
add edx,0x1放在sum_counter的那个位置？我的意思是，它是否试图将分支的条件与分支远离开来？sum_counter循环体很小，处理器可能会一起解码所有指令，在执行add edx,0x1之前进行预测。我们如何知道sum_counter比其他函数更快，因为条件是早期计算而不是条件计算速度更快？sum_sentinel中的分支条件依赖于内存访问。 - Hadi Braissum_counter 变量有更多的指令、更多的总 uops 等。改变的是分支在数据流图中的位置：它已经向上移动（即更靠近根节点）。 - BeeOnRope乱序执行绝对是一件事情（不仅编译器，甚至处理器芯片本身也可以重新排序指令），但它更有助于解决由数据依赖引起的流水线停顿问题，而不是由预测错误引起的问题。
在控制流场景中的好处受到限制，因为在大多数架构上，条件分支指令仅基于标志寄存器做出决策，而不是基于通用寄存器。除非介入的“工作”非常不寻常，否则很难提前设置标志寄存器，因为大多数指令都会改变标志寄存器（在大多数架构上）。
也许可以通过识别组合来：
TST (reg)
J(condition)
当预先设置(reg)时，可设计为最小化停顿。这当然需要处理器的大量帮助，而不仅仅是编译器。而处理器设计者很可能会优化更一般情况下的指令早期（乱序）执行，以设置分支标志位，并将结果标志位通过管道转发，从而尽早结束停顿。
cmp/jcc（在现代x86中宏融合成单个比较和分支uop，因此它实际上直接在寄存器比较时进行分支，并产生标志输出）。没有宏融合的分支指令的实际执行（以检查预测结果）并不特殊；它具有与setcc或add-with-carry一样的正常数据依赖标志。你对标志被“通过管道转发”进行描述使其听起来像是被特殊处理了，但实际上并非如此。 - Peter Cordescmp放在前面...这会导致跳转可见的错误标志。他可以使用sub提前进行比较，然后使用tst+j(cc)一起执行，但正如你所说，OOO执行引擎已经识别了cmp+j(cc)，因此尝试提前执行比较是没有意义的。 - Ben Voigtcmp不是有效的汇编实现方式，而且做额外的工作来比较寄存器（cmp/setcc为后面的test/jnz做准备）是没有意义的。无论如何，是的，a<b不是一个好的例子；如果计算a和/或b的成本很高，那么将其放在前面可能是有益的，特别是如果这导致您正在使用的优化编译器生成的汇编代码发生变化。（不能保证源代码排序会产生任何效果！） - Peter Cordesjcc或者融合的cmp/jcc都像其他指令一样按照最早准备好的先执行。分支uops不会被优先执行，所以只有当它们的输入（标志或寄存器）准备好并且有空闲的执行端口时才会执行。（Haswell只在p6上运行预测为taken的分支，或者在p0或p6上运行预测为not-taken的分支）。如果有很多更早的独立指令，即使它的输入早已准备好，jcc也可能不会早执行。（与@Bee的低ILP不同） - Peter Cordesaddcc与add。 ARM Thumb模式使得adds（加和设置标志）优于add，但MIPS甚至没有标志，而对于更复杂的条件，您需要将其比较到寄存器中。但是，是的，在x86上，长时间尝试避免设置标志位是不值得的（尽管在顺序Pentium上将cmp放在jcc几个指令之前是一种有用的优化）。其他一些RISC也具有由大多数指令设置的标志，例如x86，我想。 - Peter Cordes