为什么打破LZCNT的“输出依赖”很重要？

Question

在基准测试时，我测量到的吞吐量比我计算的低得多，我将其缩小到LZCNT指令（它也发生在TZCNT中），如以下基准测试所示：

  xor ecx, ecx
_benchloop:
  lzcnt eax, edx
  add ecx, 1
  jnz _benchloop

和：

  xor ecx, ecx
_benchloop:
  xor eax, eax  ; this shouldn't help, but it does
  lzcnt eax, edx
  add ecx, 1
  jnz _benchloop

我是在4770K上运行的，所以LZCNT和TZCNT不是作为BSR/BSF执行的。

这是怎么回事？

Answer 1

这只是Intel Haswell CPU和之前几个¹CPU的微架构的一个限制。在Skylake-S（客户端）中，已修复了TZCNT和LZCNT的问题，但在Cannon Lake中修复之前，POPCNT的问题仍然存在。

在这些微体系结构上，tzcnt、lzcnt和popcnt的目标操作数被视为输入依赖项，尽管语义上不是。现在我怀疑这是一个真正的“bug”：如果它只是一个无意的行为/疏忽，我想它应该已经在几个新的微架构中被修复了。

最有可能的是基于以下两个因素之一或两者的设计折衷：

>

POPCNT、LZCNT和TZCNT的硬件可能都与现有的BSF和BSR指令共享。现在，BSF和BSR对于全位零输入的特殊情况确实依赖于先前的目的地值²，因为Intel芯片在这种情况下不修改目的地。因此，组合硬件的最简单设计完全有可能导致在同一单元上执行的其他类似指令继承相同的依赖关系。

绝大多数x86双操作数ALU指令都依赖于目标操作数，因为它也被用作源。受影响的三条指令有些独特，因为它们是一元运算符，但与现有的一元运算符（如not和neg)不同，它们具有不同的源和目标操作数，这使得它们在表面上类似于大多数2输入指令。也许重命名器/调度器电路没有区分这些一元带两个寄存器操作数的特殊情况，而绝大多数简单共享的源/目的地2输入指令没有这种依赖关系。

事实上，对于popcnt，Intel已经发布了各种勘误表，涵盖了虚假依赖项问题，如Haswell Desktop的HSD146和Skylake的SKL029，内容如下：

POPCNT指令执行时间可能比预期的长

使用32位或64位操作数的问题POPCNT指令执行可能会被延迟，直到先前的非依赖指令已经执行。

解决方案无标识

我总是发现这个勘误表不寻常，因为它并不能真正识别出任何类型的功能缺陷或不符合规范，而实际上所有其他勘误表都是如此。Intel并没有真正为OoO执行引擎记录一个具体的性能模型，而且在过去的几年里，还有很多其他性能“错误”出现了又消失了（其中许多错误的影响比这个很小的问题大得多），这些错误没有在勘误表中记录下来。不过，这也许提供了一些证据，表明它可以被认为是一个bug。奇怪的是，勘误表从未扩展到包括tzcnt或lzcnt，它们在引入时有相同的问题。

¹WellTZCNT和LZCNT只在Haswell中出现，但在Nehalem中引入的POPCNT也存在这个问题--但错误依赖问题可能只在Sandy Bridge或更高版本中存在。

²实际上，虽然在ISA文档中没有记录，因为全零输入的结果在Intel手册中没有定义。然而，在这种情况下，大多数或所有Intel芯片实现的行为都是保持目标寄存器不变。