我目前正在查看 Agner Fog 的 instruction tables了解常见指令的延迟。
我希望我没有错过文档中这个问题的答案，但是谁能向我解释为什么某些指令没有延迟条目？
例如，操作数为 r,r,m 的 PEXT 指令的延迟对于 Skylake 留空？
丢失延迟的解释是什么，为什么一开始就很难获得延迟(如果是这种情况)？
最佳答案
IDK 为什么 Agner 在他的电子表格中将一些单元格留空。我认为这些都是手工输入的，因为至少有几个相当明确的错别字，例如5而不是 0.5对于某些东西的吞吐量(内存源 vinserti128 或其他东西，IIRC)。
解释是，除了您可以从 CPU 通常的工作方式推断出的信息之外，还有零信息。即通常有一个单独的负载 uop 为 ALU uop 供电，并且通常与寄存器源的 ALU uop 相同。但是一些指令可以使用广播负载，例如天湖vpsrld具有内存源移位计数(低元素适用于所有)看起来它使用广播加载 uop 而不是其通常的 ALU shuffle 来提供可变移位 uop(如 vpsrlvd 1 uop for p01)。
对于具有多个输入的多 uop 指令，Agner 仍然只列出 1 个延迟数。这不是一个完整的画面。有时第一个 uop 只需要一个输入，因此延迟来自 a -> result > b -> result .例如他列出了vpsrld (SKL 上的 p01 p5 为 2 uops)作为 1c 吞吐量/1c 延迟。两个输入都为 1c 显然是不可能的。据推测，Agner 测量了数据输入 -> 输出延迟，轮类计数的广播偏离了关键路径。 (我正在推断 p5 uops 正在做什么，因为它只是 p5:shuffle 端口。而且 SKL 有 1 uop 可变计数移位。并且不需要内存中的移位计数。显而易见的结论是这是广播随机播放或加载。)
要获得更完整的延迟数据，请参阅 https://www.uops.info/table.html
它有 a full latency breakdown for pext r64, r64, m64 :
- Measurements: Latencies:
- Latency operand 2 → 1: 3
- Latency operand 3 → 1 (address): 8
- Latency operand 3 → 1 (memory): ≤7
到目前为止，他们大多只有 Intel CPU(但也有 Zen)，但数据来自自动化测试，并分别测试每个输入到每个输出。还列出了 IACA 数据。 对于每条指令的每种形式，都有一个指向其详细测试结果的链接。
此外，他们对多 uop 指令的 uop 分割更加小心，例如
movbe r64, m64不是 2p0156 + p23，而是 p06 p15 p23(例如 bswap r64，Agner 确实得到了正确的结果)。
关于assembly - 指令表中缺少延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57696901/