为何优先选用NOP而非无条件跳转指令？

在函数中预留空间给运行时补丁时，我们通常会用纯NOP指令块（比如汇编指令 .nops 16），而非jmp 0f加短NOP或者重复跳转的写法。后者的优势是CPU执行第一条跳转就能跳过剩余预留空间，但这种方式始终没成为主流，核心原因和性能阈值问题可以拆解如下：

为什么跳转方式未被广泛应用？ #

• 分支预测器（BTB）资源挤占：每条无条件跳转都会占用分支目标缓冲区（BTB）的一个条目。如果代码中存在大量这类预留块，BTB会被无关分支占满，导致真正需要预测的业务分支命中率下降，反而拖慢整体性能。而多字节NOP完全不触发分支逻辑，不会消耗BTB资源。
• 指令解码效率更低：多字节NOP的密度和解码效率更高。比如x86架构下，0x0f 0x1f 0x40 0x00是4字节单条NOP指令，而用jmp 0f（2字节）加2字节NOP的方式，同样4字节空间需要解码2条指令。CPU的解码单元有吞吐量限制，更少的指令数意味着更快的解码速度。
• 补丁灵活性差：跳转方式的预留空间大小是固定的，如果后续补丁需要的字节数少于预留值，剩下的空间仍需用NOP填充；而纯NOP块可以灵活裁剪，不管补丁字节数多少，剩余部分直接用NOP补全即可，无需调整跳转目标。

预留字节数超过阈值时，跳转方式是否有性能优势？ #

当预留空间足够大时，跳转方式确实可能在性能上超过纯NOP块，但这个场景非常有限：

• 阈值的实际范围：不同CPU架构的阈值差异较大，一般当预留空间超过32字节左右时，执行所有NOP的开销会逐渐超过一次预测正确的无条件跳转开销。但要注意，现代CPU对多字节NOP有优化——部分多字节NOP会被解码单元直接标记为空操作，不进入执行流水线，这会拉高阈值。
• 前提条件苛刻：只有当预留块所在的代码路径被频繁执行时，性能差异才会显现。如果预留块位于冷路径（很少被走到的代码），两种方式的性能差异可以忽略不计。
• 架构差异影响：Intel和AMD的分支预测机制、NOP处理逻辑不同，比如AMD的Zen架构对分支的处理开销略低于Intel的某些架构，阈值可能会更低一些。

总结来说，跳转方式的性能优势只在极端场景下存在，而其带来的BTB资源占用、解码效率问题以及补丁灵活性缺陷，使得纯NOP块依然是运行时补丁预留空间的主流选择。

内容的提问来源于stack exchange，提问作者Joseph Garvin