使用 Intel 编译器的 Windows 和 Linux 之间的性能差异：查看程序集

Posted 2023-02-14

【中文标题】使用 Intel 编译器的 Windows 和 Linux 之间的性能差异：查看程序集

【英文标题】：Performance difference between Windows and Linux using Intel compiler: looking at the assembly

【发布时间】：2017-03-24 04:48:17

【问题描述】：

我正在 Windows 和 Linux (x86-64) 上运行一个程序。它使用相同的编译器（Intel Parallel Studio XE 2017）和相同的选项编译，Windows 版本比 Linux 版本快 3 倍。罪魁祸首是对std::erf 的调用，这两种情况都在英特尔数学库中得到解决（默认情况下，它在 Windows 上动态链接，在 Linux 上静态链接，但在 Linux 上使用动态链接可获得相同的性能）。

这是一个重现问题的简单程序。

#include <cmath>
#include <cstdio>

int main() 
  int n = 100000000;
  float sum = 1.0f;

  for (int k = 0; k < n; k++) 
    sum += std::erf(sum);
  

  std::printf("%7.2f\n", sum);

当我使用 vTune 分析这个程序时，我发现程序集在 Windows 和 Linux 版本之间有点不同。这是 Windows 上的调用站点（循环）

Block 3:
"vmovaps xmm0, xmm6"
call 0x1400023e0 <erff>
Block 4:
inc ebx
"vaddss xmm6, xmm6, xmm0"
"cmp ebx, 0x5f5e100"
jl 0x14000103f <Block 3>

以及在 Windows 上调用的 erf 函数的开头

Block 1:
push rbp
"sub rsp, 0x40"
"lea rbp, ptr [rsp+0x20]"
"lea rcx, ptr [rip-0xa6c81]"
"movd edx, xmm0"
"movups xmmword ptr [rbp+0x10], xmm6"
"movss dword ptr [rbp+0x30], xmm0"
"mov eax, edx"
"and edx, 0x7fffffff"
"and eax, 0x80000000"
"add eax, 0x3f800000"
"mov dword ptr [rbp], eax"
"movss xmm6, dword ptr [rbp]"
"cmp edx, 0x7f800000"
...

在 Linux 上，代码有点不同。调用地点是：

Block 3
"vmovaps %xmm1, %xmm0"
"vmovssl  %xmm1, (%rsp)"
callq  0x400bc0 <erff>
Block 4
inc %r12d
"vmovssl  (%rsp), %xmm1"
"vaddss %xmm0, %xmm1, %xmm1"   <-------- hotspot here
"cmp $0x5f5e100, %r12d"
jl 0x400b6b <Block 3>

而被调用函数（erf）的开头是：

"movd %xmm0, %edx"
"movssl  %xmm0, -0x10(%rsp)"   <-------- hotspot here
"mov %edx, %eax"
"and $0x7fffffff, %edx"
"and $0x80000000, %eax"
"add $0x3f800000, %eax"
"movl  %eax, -0x18(%rsp)"
"movssl  -0x18(%rsp), %xmm0"
"cmp $0x7f800000, %edx"
jnl 0x400dac <Block 8>
...

我已经展示了在 Linux 上浪费时间的 2 点。

有没有人足够了解汇编来解释这两个代码的区别以及为什么 Linux 版本慢了 3 倍？

【问题讨论】：

硬件一样吗？

是的，同样的硬件。我已经在适用于 Windows 和 Linux 的核心 i7 Haswell 以及适用于 Windows 和 Linux 的 Xeon Broadwell 上测试了这个案例。结果相同。在core i7上我也在macOS上测试过，速度和Windows版本一样。

Linux 是否在虚拟机中运行？

结果在数值上是否相同？英特尔的实现可能更准确。当然，确定这一点并非易事。

Linux 版本正在保存并稍后将 xmm1 恢复到/从块 3 和块 4 中的 ram，但 Windows 版本正在保存（我假设稍后恢复，但上面没有显示）xmm6 到 /来自内存。

【参考方案1】：

根据 Windows 和 GNU/Linux 上各自的调用约定，在这两种情况下，参数和结果仅在寄存器中传递。

在 GNU/Linux 变体中，xmm1 用于累积总和。由于它是一个 call-clobbered 寄存器（也称为 caller-saved），它在每次调用时存储（和恢复）在调用者的堆栈帧中。

在 Windows 变体中，xmm6 用于累加总和。此寄存器在 Windows 调用约定中是被调用者保存的（但不是在 GNU/Linux 中）。

因此，总而言之，GNU/Linux 版本保存/恢复xmm0（在被调用者[1] 中）和xmm1（在调用者中），而 Windows 版本仅保存/恢复xmm6（在被调用者中）。

[1] 需要查看 std::errf 以找出原因。

【讨论】：

寄存器是被调用者保存的事实是不是在 Windows 上总是遵循而不在 Linux 上？

编译器总是尊重 ABI，只是不同的 ABI 以不同的方式定义调用者和被调用者保存的寄存器集。

实际上，ABI 只需要在编译器看不到定义的外部调用中得到尊重。否则（当它可以看到被调用者的定义时）它可以执行它喜欢的任何转换，而不会改变定义良好的代码的结果，包括内联或使用自定义调用约定。

@R.，确实，对于“非导出”函数以及所有调用站点都是已知的。

@chill：不必知道所有呼叫站点。编译器可以（并且 gcc 确实）在外部可访问（并非所有调用站点都知道）并且以可以受益于不同调用约定（或过程间常量传播等）的方式在本地使用时发出函数的多个版本。 )。

【参考方案2】：

使用 Visual Studio 2015，Win 7 64 位模式，我发现以下代码用于 erf() 中使用的一些路径（未显示所有路径）。每条路径涉及从内存读取的多达 8 个（对于其他路径可能更多）常量，因此单个存储/加载来保存寄存器似乎不太可能导致 Linux 和 Windows 之间的 3 倍速度差异。至于保存/恢复，此示例保存和恢复 xmm6 和 xmm7。至于时间，原帖中的程序在 Intel 3770K (3.5ghz cpu) (VS2015 / Win 7 64 bit) 上耗时约 0.86 秒。更新 - 我后来确定在程序 10^8 循环（每个循环约 3 纳秒）的情况下，保存和恢复 xmm 寄存器的开销约为 0.03 秒。

000007FEEE25CF90  mov         rax,rsp  
000007FEEE25CF93  movss       dword ptr [rax+8],xmm0  
000007FEEE25CF98  sub         rsp,48h  
000007FEEE25CF9C  movaps      xmmword ptr [rax-18h],xmm6  
000007FEEE25CFA0  lea         rcx,[rax+8]  
000007FEEE25CFA4  movaps      xmmword ptr [rax-28h],xmm7  
000007FEEE25CFA8  movaps      xmm6,xmm0  
000007FEEE25CFAB  call        000007FEEE266370  
000007FEEE25CFB0  movsx       ecx,ax  
000007FEEE25CFB3  test        ecx,ecx  
000007FEEE25CFB5  je          000007FEEE25D0AF  
000007FEEE25CFBB  sub         ecx,1  
000007FEEE25CFBE  je          000007FEEE25D08F  
000007FEEE25CFC4  cmp         ecx,1  
000007FEEE25CFC7  je          000007FEEE25D0AF  
000007FEEE25CFCD  xorps       xmm7,xmm7  
000007FEEE25CFD0  movaps      xmm2,xmm6  
000007FEEE25CFD3  comiss      xmm7,xmm6  
000007FEEE25CFD6  jbe         000007FEEE25CFDF  
000007FEEE25CFD8  xorps       xmm2,xmmword ptr [7FEEE2991E0h]  
000007FEEE25CFDF  movss       xmm0,dword ptr [7FEEE298E50h]  
000007FEEE25CFE7  comiss      xmm0,xmm2  
000007FEEE25CFEA  jbe         000007FEEE25D053  
000007FEEE25CFEC  movaps      xmm2,xmm6  
000007FEEE25CFEF  mulss       xmm2,xmm6  
000007FEEE25CFF3  movaps      xmm0,xmm2  
000007FEEE25CFF6  movaps      xmm1,xmm2  
000007FEEE25CFF9  mulss       xmm0,dword ptr [7FEEE298B34h]  
000007FEEE25D001  mulss       xmm1,dword ptr [7FEEE298B5Ch]  
000007FEEE25D009  addss       xmm0,dword ptr [7FEEE298B8Ch]  
000007FEEE25D011  addss       xmm1,dword ptr [7FEEE298B9Ch]  
000007FEEE25D019  mulss       xmm0,xmm2  
000007FEEE25D01D  mulss       xmm1,xmm2  
000007FEEE25D021  addss       xmm0,dword ptr [7FEEE298BB8h]  
000007FEEE25D029  addss       xmm1,dword ptr [7FEEE298C88h]  
000007FEEE25D031  mulss       xmm0,xmm2  
000007FEEE25D035  mulss       xmm1,xmm2  
000007FEEE25D039  addss       xmm0,dword ptr [7FEEE298DC8h]  
000007FEEE25D041  addss       xmm1,dword ptr [7FEEE298D8Ch]  
000007FEEE25D049  divss       xmm0,xmm1  
000007FEEE25D04D  mulss       xmm0,xmm6  
000007FEEE25D051  jmp         000007FEEE25D0B2  
000007FEEE25D053  movss       xmm1,dword ptr [7FEEE299028h]  
000007FEEE25D05B  comiss      xmm1,xmm2  
000007FEEE25D05E  jbe         000007FEEE25D076  
000007FEEE25D060  movaps      xmm0,xmm2  
000007FEEE25D063  call        000007FEEE25CF04  
000007FEEE25D068  movss       xmm1,dword ptr [7FEEE298D8Ch]  
000007FEEE25D070  subss       xmm1,xmm0  
000007FEEE25D074  jmp         000007FEEE25D07E  
000007FEEE25D076  movss       xmm1,dword ptr [7FEEE298D8Ch]  
000007FEEE25D07E  comiss      xmm7,xmm6  
000007FEEE25D081  jbe         000007FEEE25D08A  
000007FEEE25D083  xorps       xmm1,xmmword ptr [7FEEE2991E0h]  
000007FEEE25D08A  movaps      xmm0,xmm1  
000007FEEE25D08D  jmp         000007FEEE25D0B2  
000007FEEE25D08F  mov         eax,8000h  
000007FEEE25D094  test        word ptr [rsp+52h],ax  
000007FEEE25D099  je          000007FEEE25D0A5  
000007FEEE25D09B  movss       xmm0,dword ptr [7FEEE2990DCh]  
000007FEEE25D0A3  jmp         000007FEEE25D0B2  
000007FEEE25D0A5  movss       xmm0,dword ptr [7FEEE298D8Ch]  
000007FEEE25D0AD  jmp         000007FEEE25D0B2  
000007FEEE25D0AF  movaps      xmm0,xmm6  
000007FEEE25D0B2  movaps      xmm6,xmmword ptr [rsp+30h]  
000007FEEE25D0B7  movaps      xmm7,xmmword ptr [rsp+20h]  
000007FEEE25D0BC  add         rsp,48h  
000007FEEE25D0C0  ret  

【讨论】：

每条路径涉及从内存读取的多达 8 个（其他路径可能更多）常量，在现代 CPU（Intel SnB 系列，或AMD k8 及更高版本），以及延迟：乱序执行可以与任何东西重叠，因为地址是提前知道的。即它们可以在指令的寄存器输入准备就绪时完成并准备好，因此它们不一定会延长依赖链。我会更担心 mulss/addss 链！

你说得对，它看起来很奇怪。从 C 开始，OP 的测试函数应该只是 erf() 延迟的瓶颈，加上 3c 用于 FP 添加（或 4 在 SKL），并且可选地 + 另一个 5 或 6 个周期用于 XMM 溢出/重新加载。我没有仔细阅读asm。也许存储/重新加载会降低其他效率。

@PeterCordes - 跟进，我用一个只返回的汇编例程和一个存储/加载 xmm0 并返回的汇编例程替换了 erf。 xmm0 开销的存储/加载为 0.03 秒，10^8 个循环，== 3 纳秒/存储/加载指令对。使用 erf() 将 0.03 秒的存储/加载开销与 0.86 秒的总时间进行比较（同样是 10^8 循环）。