为什么 x86 位串操作指令对于 memory 目标很慢？ （防弹少年团、比特瑞、比特币）

Question

Agner发现，在大多数支持它们的处理器上，应用于 memory 操作数的 x86 位操作指令（btr bts btc，无锁）比其他读-修改-写指令（如 add、xor 等）慢。 为什么是这样？ 这些说明似乎很容易实现。

是否因为实际加载的地址与 memory 操作数指定的地址不同，这混淆了一些跟踪 memory 访问的前端机制？ 这似乎有道理，但我不认为它会影响吞吐量（至少不会那么大）； 只有延迟。

Answer 1

是不是因为实际加载的地址和memory操作数指定的地址不一样

是的，很明显，这就是它与记忆目的地转移的区别。

reg-reg 版本是 1 uop，在 Intel 上有 1 个周期延迟，在 Intel Haswell 和更高版本上运行在执行端口 0 或 6 上，例如，与班次相同。 （将索引解码为 1-hot mask 比一般移位器便宜，但由于有移位单元，英特尔可能只是使用它们。）

出于某种原因，AMD 将bts reg,reg运行为 2 微指令，比简单的移位慢。 IDK 为什么，也许与 FLAGS 设置有关。

bts mem, imm8也很正常，Intel 上有 3 个前端 uops。 xor mem, imm8只有 2 个前端 uops，但那是因为它可以微熔断 load+xor。 not mem是 3 个前端 uops，只是微融合了存储地址和存储 uop 指令。

这会混淆一些用于跟踪 memory 访问的前端机制吗？

不，前端不跟踪 memory 访问，那是后端。

它的部分速度很慢，因为它是作为多个 uops 实现的； 即使你在不同的指示下做一件事情，也会很痛。 在 Intel Haswell 和 Alder Lake（可能全部介于两者之间）上， bts mem, r32是 10 个前端微指令，而bts mem, imm8是 3 个前端微指令

因为它不能直接使用通常的地址生成硬件，所以它在微代码中实现为多个 uops，大概是像 LEA 之类的东西从正常寻址模式变成一个临时的，并添加(bit_index>>6) * 4到那个索引双字或类似的东西。 哦，也许它是 10 微指令的原因是它总是想访问包含该位的对齐双字，而不仅仅是[]寻址模式中地址的 4 的倍数偏移量，例如[rax + rdx*4 + 123] 。

对于您知道位串的开头已对齐的正常情况，手动执行此操作更有效，因此您可以shr位索引以获得加载/ bts reg,reg （1 uop）/存储的双字索引。 这比bts [mem], reg需要更少的微指令。 请注意bts reg,reg截断/包装位索引，因此如果您正确安排事情，模数是免费的。 例如埃拉托色尼筛法。 另外memory 目标 BTS 怎么会比 load / BTS reg,reg / store 慢很多？

---

但是 Agner Fog 和https://uops.info/都在 Haswell / Alder Lake P 核上测量了 5 个周期的吞吐量，明显低于前端瓶颈（或任何每个端口的后端瓶颈）所占的比例.

我不知道是什么原因造成的。 实际的加载和存储微指令应该只是正常的，输入来自内部临时寄存器，但就存储缓冲区和加载缓冲区中的地址而言，仍然是正常的加载微指令和存储微指令。 （英特尔将其统称为 Memory 订单缓冲区 = MOB。）

我不希望它是内存依赖性预测的特例，因为当加载 uop 执行时会发生这种情况（并且之前的存储地址 uops 尚未执行，因此地址是一些以前的存储仍然未知。）

TODO：运行一些实验，看看是否有任何其他指令与bts mem,reg混合在一起会减慢它的速度，竞争它瓶颈的任何资源。

它看起来不像https://uops.info/的基准测试错误（例如，每次都使用相同的地址并在存储转发延迟上停滞）。 他们的测试包括一些使用不同偏移量的展开序列。 例如，针对bts m64, r64的Haswell 吞吐量测试每次都使用相同的地址（ bts qword ptr [r14], r8 ）测量 6.02 或 6.0 个周期的吞吐量，或者在展开像bts [r14],r8这样的重复序列时每个 BTS 平均 5.0 个周期bts [r14],r8 ; bts [r14+0x8],r8 ; ...; bts [r14+0x38],r8 。 即使对于覆盖两个相邻高速缓存行的 16 条独立指令序列，每次迭代仍然是相同的 5 个周期。