为什么添加xorps指令会使使用cvtsi2ss和addss的函数快5倍？

Question

我在使用Google Benchmark优化函数时遇到了麻烦，在某些情况下，我的代码出乎意料地慢了下来。我开始对它进行实验，查看编译后的html" target="_blank">程序集，最终提出了一个展示该问题的最小测试用例。这是我提出的展示这种减速的组件：

    .text
test:
    #xorps  %xmm0, %xmm0
    cvtsi2ss    %edi, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    addss   %xmm0, %xmm0
    retq
    .global test

此函数遵循GCC/Clang的x86-64调用约定，用于函数声明extern"C"浮点测试（int）；注意注释掉的xorps指令。取消注释此指令显着提高了函数的性能。使用我的机器进行i7-8700K测试，Google基准测试显示，没有xorps指令的函数需要8.54ns（CPU），而带有xorps指令的函数需要1.48ns。我已经在具有各种操作系统、处理器、处理器代和不同处理器制造商（Intel和AMD）的多台计算机上进行了测试，它们都表现出类似的性能差异。重复addss指令会使减速更加明显（在一定程度上），并且这种减速仍然会使用这里的其他指令（例如mulss）甚至混合指令发生，只要它们都以某种方式依赖于%xmm0中的值。值得指出的是，只有调用xorps每个函数调用才能提高性能。使用循环（如Google Benchmark所做的那样）对性能进行采样（在循环之外使用xorps调用仍然显示出较慢的性能。

由于这是一个专门添加指令提高性能的情况，这似乎是由CPU中真正低级的东西引起的。由于它发生在各种各样的CPU中，这似乎是故意的。但是，我找不到任何留档来解释为什么会发生这种情况。有人能解释一下这里发生了什么吗？这个问题似乎取决于复杂的因素，因为我在原始代码中看到的减速只发生在特定的优化级别（-O2，有时是-O1，但不是-O），没有内联，并且使用特定的编译器（Clang，但不是GCC）。

Answer 1

异或归零打破了dep链，允许无序exec发挥其魔力。因此，您的瓶颈是吞吐量（0.5个周期），而不是延迟（4个周期）。

您的CPU是Skylake派生的，所以这些是数字；早期的英特尔使用专用的FP-add执行单元而不是在FMA单元上运行它有3个周期延迟，1个周期吞吐量。https://agner.org/optimize/.可能函数调用/ret开销会阻止您从流水线FMA单元中的8个动态addssuops的延迟*带宽乘积中看到完整的8倍预期加速；如果您从单个函数中的循环中删除xorpsdep-中断，您应该会获得该加速。

GCC倾向于对虚假依赖非常“小心”，花费额外的指令（前端带宽）来打破它们以防万一。在前端出现瓶颈的代码中（或者在总代码大小/uop缓存占用是一个因素的情况下），如果寄存器实际上已经及时准备好，那么这会降低性能。

Clang/LLVM对此是鲁莽和漫不经心的，通常不会费心避免对不在当前函数中写入的寄存器的错误依赖。（即假设/假装寄存器对函数条目是“冷的”）。正如您在评论中展示的，clang确实避免了在一个函数内循环时通过异或零来创建循环携带的dep链，而不是通过对同一个函数的多次调用。

在某些情况下，与32位reg相比，Clang甚至无缘无故地使用8位GP整数部分寄存器，这不会节省任何代码大小或指令。通常这可能没问题，但例如，如果调用方（或同级函数调用）在调用时仍有缓存未命中负载，则存在耦合到长dep链或创建循环承载依赖链的风险。

有关OoO exec如何重叠短到中等长度的独立dep链的更多信息，请参阅了解lGeofence对具有两个长依赖链的循环的影响，以增加长度。还相关：为什么mulss在Haswell上只需要3个周期，不同于Agner的指令表？（使用多个累加器展开FP循环）是关于使用多个累加器展开点积以隐藏FMA延迟。

https://www.uops.info/html-instr/CVTSI2SS_XMM_R32.html具有此指令在各种UARCHE中的性能详细信息。

正如我在中提到的，为什么sqrtsd指令的延迟会根据输入而变化？英特尔处理器

这正是AMD64通过将对32位整数寄存器的写入隐式零扩展到完整的64位寄存器而避免的问题，而不是将其保持不变（也称为合并）。为什么32位寄存器上的x86-64指令将完整64位寄存器的上部归零？（写入8位和16位寄存器确实会导致对AMD CPU的错误依赖，以及自Haswell以来的Intel）。