assembly - x86/x64 asm 中的指令重新排序 - 使用最新 CPU 进行性能优化

Question

在最近的高端 Intel CPU 上重新排序 x64 (x86-64) 指令可以获得多少性能提升(如果有的话)。在时间极其紧迫的情况下是否值得打扰？

我还想知道通过改变寄存器使用/使用额外的寄存器(如果免费)以允许在某些奇怪的情况下进行更远距离的代码移动来获得 yield 的可能性？

Answer 1

指令调度在短距离内通常不是什么大问题，因为乱序执行通常有效。在像一些 ARM 内核这样的有序 CPU 上更重要，在这些 CPU 中，在使用结果的指令之前调度负载很重要。

不过，它甚至可以在高端 x86 上提供帮助，具体取决于限制执行吞吐量的瓶颈类型。见 http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/关于 ROB 大小与物理寄存器数量的一些有趣的东西是乱序执行的限制因素。 Software-pipelining可以帮助处理乱序执行很难隐藏的长依赖链。

尽早将指令放在关键路径依赖链上会有所帮助，因为 OOO 调度通常会尝试执行最旧的就绪优先。 (见 How are x86 uops scheduled, exactly?)。

现代 CPU 是复杂的野兽，有时在您不认为它很重要的情况下重新排序会产生影响。有时无法准确猜测为什么会有所不同。不同的排序会影响解码器甚至 uop 缓存中的前端带宽，因为关于解码的 uops 如何打包到 uop 缓存(在 Intel CPU 上)中最多 6-uop 行有很多规则。例如，Branch alignment for loops involving micro-coded instructions on Intel SnB-family CPUs

有时解释很模糊。例如，在 Intel 的优化手册中，Example 3-25. Re-ordering Sequence to Improve Effectiveness of Zero-Latency MOV Instructions ，他们讨论立即覆盖零延迟 movzx 结果以更快地释放内部资源。 (我在 Haswell 和 Skylake 上尝试了示例，发现 mov-elimination 实际上在执行此操作时确实在更多时间内有效，但实际上在总周期中略慢，而不是更快。该示例旨在说明IvyBridge 的好处，它可能在其 3 个 ALU 端口上遇到瓶颈，但 HSW/SKL 仅在 dep 链中的资源冲突上成为瓶颈，并且似乎不会因为需要 ALU 端口来处理更多 movzx 指令而烦恼。)

可能这也适用于 eliminated mov instructions ，不仅仅是 movzx ，但可能不会。

如果英特尔的手册没有将其用作示例，我是否会在真正的优化情况(对于 IvyBridge)中遇到这一点，那么 IDK。 uop 发布与执行(融合域与未融合域)的性能计数器显示有多少 mov uops 被消除，但如果没有优化手册说明原因，几乎不可能弄清楚为什么会发生。重新排序附近的独立指令只是为了尝试一些东西可以作为调整的最后一步，但在这一点上它是巫毒/黑魔法/猜测。

正如 Margaret 指出的那样，除了简单的调度之外，还有其他理由对指令进行重新排序。见 Agner Fog's optimization and microarchitecture guides ，以及 x86 中的其他资源标记 wiki 以了解更多信息。

例如分组cmp/jcc和 test/jcc由于宏观融合，在一起总是一个好主意。当你用 -march=haswell 编译时，你的编译器会为你做这件事或者其他什么，因为这可以启用 -mtune=haswell .

如果它让您避免一些 mov，它还可以打开其他优化机会。指令或溢出/重新加载，但这不仅仅是调度指令。