为什么条件移动不容易发生分支预测失败？
在阅读了这篇文章（关于StackOverflow的回答）（在优化部分）之后，我想知道为什么条件移动不容易受到分支预测失败的影响。我在这里找到了一篇关于cond移动的文章（由AMD提供的PDF格式）。同样在这里，他们宣称cond的性能优势。动作。但这是为什么呢？我看不出来。在评估ASM指令时刻，还不知道前面CMP指令的结果。
共有1个答案
如果进展顺利，现代处理器通常每个周期执行一到三条指令（如果它没有停顿，等待这些指令从先前的指令或从内存到达的数据依赖）。
上面的语句对于紧密循环非常适用，但是这不应该让您看不到一个附加的依赖关系，它可以阻止指令在其周期到来时被执行：对于要执行的指令，处理器必须在15-20个周期之前开始获取并解码它。
处理器遇到分支怎么办？获取和解码两个目标不会缩放（如果后续有更多分支，则必须并行获取指数数量的路径）。因此处理器只能提取和解码两个分支中的一个。
条件移动不需要预测，所以永远不能有这个惩罚。它与普通指令一样，具有数据依赖关系。事实上，一个条件移动比普通指令具有更多的数据依赖关系，因为数据依赖关系同时包括“条件真”和“条件假”两种情况。在有条件地将R1移动到R2的指令之后，R2的内容似乎既取决于R2的前一个值，也取决于R1。一个预测良好的条件分支允许处理器推断出更精确的依赖关系。但是数据依赖通常需要一到两个周期才能到达，如果它们需要时间到达的话。
请注意，从内存到寄存器的有条件移动有时会是一个危险的赌注：如果条件是从内存读取的值没有分配给寄存器，则您在内存上等待的时间是空的。但指令集中提供的条件移动指令通常是寄存器到寄存器的，以防止程序员出现这种错误。
-
读完这篇文章（StackOverflow上的答案）（在优化部分）后，我想知道为什么条件移动对分支预测失败并不脆弱。我在这里找到了一篇关于cond移动的文章（AMD的PDF）。同样在那里，他们声称cond的性能优势。移动。但这是为什么？我看不出来。在评估ASM指令的那一刻，前面的CMP指令的结果还不知道。
-
如果语句更多地依赖于分支预测，而v表查找更多地依赖分支目标预测，那么
-
分支目标预测（BTP）与分支预测（BP）不同。我知道BTP会找到分支将跳转到的位置，而BP只是决定可能采取哪个分支。 BTP依赖BP吗，如果BTP不使用BP来预测哪个分支被采用，它怎么可能知道分支的目标呢？ 我不明白为什么会有这么大的差异？一旦分支被预测为被占用，找到目标并不像读取指令中的地址一样简单吗？
-
我试图理解分支预测器条目何时失效。 以下是我所做的实验： 代码1： 因此，我正在多次运行此代码。我可以看到，在第一次运行之后，错误预测率会降低。分支预测器学习如何正确预测。但是，如果我一次又一次地运行这个实验（即通过将写入终端），所有的第一次迭代都是从高错误率开始的。因此，在每次执行时，这些预测单位都无效。我正在使用并且我已禁用。我还在一个孤立的核心上运行这个实验。我已经运行了这个实验几次，以确保
-
编辑：我的困惑出现了，因为通过预测哪个分支，你肯定也在有效地进行目标预测？？ 这个问题与我关于这个主题的第一个问题有内在联系： 分支预测与分支目标预测 无限循环 语句 或语句 语句的“then”子句结尾（跳过子句） 非虚函数调用 从函数返回 虚函数调用 函数指针调用 语句（如果编译为跳转表） 语句 语句（如果编译成一系列语句） 循环条件测试 和运算符 三元运算符 null 如果我有以下代码： (B
-
我的代码经常调用具有多个（不可预测的）分支的函数。当我分析时，我发现这是一个小瓶颈，大部分CPU时间用于条件JMP。 考虑以下两个函数，其中原始函数有多个显式分支。 这是一个新函数，我试图在其中删除导致瓶颈的分支。 然而，当我分析新代码时，性能只提高了大约20%，而且调用本身(对mem_funcs数组中的一个func)花费了很长时间。 第二个变量仅仅是一个更隐含的条件吗，因为CPU仍然无法预测将要