问题标签 [branch-prediction]

In the latest Intel software dev manual it describes two opcode prefixes:

These allow for explicit branch prediction of Jump instructions (opcodes likeJxx)

I remember reading a couple of years ago that on x86 explicit branch prediction was essentially a no-op in the context of gccs branch prediciton intrinsics.

I am now unclear if these x86 branch hints are a new feature or whether they are essentially no-ops in practice.

Can anyone clear this up?

(That is: Does gccs branch prediction functions generate these x86 branch hints? - and do current Intel CPUs not ignore them? - and when did this happen?)

Update:

I created a quick test program:

Disassembles to the following:

I don't see 2E or 3E ? Maybe gcc has elided them for some reason?

如何以最好的可移植方式对任意排序数组执行（几乎）无分支二进制搜索？（例如，帮助编译器生成 CMOV 指令的代码对此非常有用。）

“几乎”是指“包含尽可能少的分支”。

Last Branch Record 是指寄存器对 (MSR) 的集合，这些寄存器对 (MSR) 存储与最近执行的分支相关的源地址和目标地址。http://css.csail.mit.edu/6.858/2012/readings/ia32/ia32-3b.pdf文档有更多信息，以防您感兴趣。

• a) 有人可以知道 LBR 减慢了常见程序的程序执行速度 - CPU 和 IO 密集型吗？
• b) 当 LBR 跟踪打开时，分支预测是否会关闭？

GCC 手册仅显示了将__builtin_expect() 放置在“if”语句的整个条件周围的示例。

我还注意到，如果我使用 GCC，它不会抱怨，例如，与三元运算符一起使用，或在任何任意整数表达式中，即使是未在分支上下文中使用的表达式。

所以，我想知道它使用的潜在限制实际上是什么。

在像这样的三元运算中使用时它是否会保留其效果：

那么这个案例呢：

和这个：

因此，根据我对延迟槽的理解，它们发生在调用分支指令并且分支之后的下一条指令也从内存中加载时。这有什么意义？您不希望分支之后的代码在分支被占用的情况下不会运行吗？如果分支没有被占用，是否可以节省时间？

我正在看一个流水线图，似乎分支后的指令无论如何都在执行..

我有一个Compare()看起来像这样的函数：

我决定优化以避免分支：

然后我通过这样做进行测试：

结果：

我会说案例关闭，避免分支FTW。但是为了完整起见，我替换了

和：

并得到了完全相同的测量结果，约为 3.14ns。据推测，那时没有分支发生，编译器实际上正在重写Compare()以避免该if语句。但是，为什么Compare2()更快呢？

不幸的是，我是汇编代码文盲，否则我会尝试自己回答这个问题。

编辑：下面是一些程序集：

现在，执行测试的实际代码可能正在使用上述两个函数的内联版本，因此这可能是要分析的错误代码。话虽如此，我在 中看到一个jmp命令Compare()，所以我认为这意味着它正在分支。如果是这样，我想这个问题就变成了：为什么分支预测器不能提高Compare()我a[i]从rand()%2to true（或false就此而言）改变时的性能？

EDIT2：我用“分支”替换了“分支预测”，以使我的帖子更明智。

更新

将汇编的第二行更改为实际使用的助记符 ( mflr) 并在底部添加了更多信息。

我遇到了一些类似于以下的代码（使用 gcc）（释义）：

...其中b指令（ppc）是一个简短的 jmp 并且mflr正在获取“链接寄存器”的内容——这在某些方面类似于程序计数器。对于英特尔代码，我也看到过这种情况（参见这个问题中接受的答案）。

该分支充当无操作...我的问题：这有什么目的？

我猜它与分支预测有关，但到目前为止，我只发现人们在搜索时使用这个成语的代码。

看起来我在分支预测猜测上错了。 mflr获取链接寄存器的内容。

所以，我的问题归结为：为什么需要分支。

我有一个小程序，它应该计算 2 位分支预测器的成功预测百分比。我已经完成了所有工作，但我的输出不是我所期望的，百分比停止在 91% 左右，而不是我认为应该是 98% 或 99%。我认为问题可能在于如何将掩码应用于地址。有人可以查看我的代码并验证这是否是问题所在。

该程序遍历一个文件，该文件具有 gcc 编译器运行的分支历史记录，该历史记录由大约 1792 个地址和一个数字列组成，其中 1 表示已采用分支，0 表示未采用分支。

这是输出：

在我想优化此功能的上一个问题上：

一位用户评论说我可以替换s1i == s2[j] ? 0 : 1为((s1i - s2[j]) & 0x80) >> 7以防止条件跳转。这个把戏是错误的，用户删除了他的评论，但我想知道是否真的有办法做到这一点。

我想知道如何用 C、C++ 或汇编语言为 x64 处理器编写高效的跳转表。输入是预先知道的，但无法通过算法进行预测。假设我可以在输入流中尽可能地向前看，有什么方法可以动态地告诉 CPU 下一个分支要去哪个地址？

本质上，我想以编程方式更新分支目标缓冲区。但是，如果程序员通过查看数据提前知道下一个分支的去向，但处理器无法从过去的模式中确定这一点，我会接受任何允许我避免刷新管道的方法。

意识到这是一个非常具体的问题，我可能无法正确传达它，这里有一些替代措辞：

Cell 处理器上是否有与hbrHint for Branch 等效的 x64？

它是否有助于在cmp条件分支之前移动程序集，就像在 Itanium 中所做的那样？

间接跳转的预测目标是否基于寄存器值而不是最后使用的地址？

谢谢！