更改完全不相关的代码时,Visual Studio C++ 编译器生成的代码速度慢 3 倍

2023-12-26

我有一个嵌套的 for 循环,它生成以下程序集:

# branch target labels manually added for readability
002E20F8  mov         ebx,esi  
002E20FA  mov         dword ptr [ebp-10h],3B9ACA00h  
002E2101  sub         ebx,edi  
002E2103  add         ebx,7  
002E2106  shr         ebx,3  
002E2109  nop         dword ptr [eax]  
  outer_loop:
002E2110  xor         eax,eax  
002E2112  xor         ecx,ecx  
002E2114  cmp         edi,esi  
002E2116  mov         edx,ebx  
002E2118  cmova       edx,eax  
002E211B  mov         eax,edi  
002E211D  test        edx,edx 
002E211F  je          main+107h (02E2137h)  ;end_innerloop

  inner_loop:           
002E2121  movsd       xmm0,mmword ptr [eax] 
002E2125  inc         ecx                     ; inc/addsd swapped
002E2126  addsd       xmm0,mmword ptr [k]   
002E212B  add         eax,8  
002E212E  movsd       mmword ptr [k],xmm0  
002E2133  cmp         ecx,edx  
002E2135  jne         main+0F1h (02E2121h)  ;inner_loop
  end_innerloop:        
002E2137  sub         dword ptr [ebp-10h],1  
002E213B  jne         main+0E0h (02E2110h)   ;outer_loop

如果我在嵌套 for 循环之前更改一行代码来简单地声明一个int然后在for循环之后打印出来。这使得编译器拉出存储/重新加载k跳出循环。

问题的第一个版本将此描述为“以稍微不同的顺序生成指令”。 (编者注:也许我应该把这个分析/更正留给答案?)

003520F8  mov         ebx,esi  
003520FA  mov         dword ptr [ebp-10h],3B9ACA00h  
00352101  sub         ebx,edi  
00352103  add         ebx,7  
00352106  shr         ebx,3  
00352109  nop         dword ptr [eax]  
  outer_loop:
00352110  xor         eax,eax  
00352112  xor         ecx,ecx  
00352114  cmp         edi,esi  
00352116  mov         edx,ebx  
00352118  cmova       edx,eax  
0035211B  mov         eax,edi  
0035211D  test        edx,edx  
0035211F  je          main+107h (0352137h) ;end_innerloop

00352121  movsd       xmm0,mmword ptr [k]    ; load of k hoisted out of the loop.  Strangely not optimized to xorpd xmm0,xmm0

  inner_loop:
00352126  addsd       xmm0,mmword ptr [eax]
0035212A  inc         ecx  
0035212B  add         eax,8  
0035212E  cmp         ecx,edx  
00352130  jne         main+0F6h (0352126h)  ;inner_loop

00352132  movsd       mmword ptr [k],xmm0     ; movsd in different place.

  end_innerloop:
00352137  sub         dword ptr [ebp-10h],1  
0035213B  jne         main+0E0h (0352110h)  ;outer_loop

编译器的第二种安排速度快了 3 倍。我对此感到有些震惊。有谁知道发生了什么事吗?

这是用 Visual Studio 2015 编译的。

编译器标志(如果需要,我可以添加更多):

优化:最大化速度/O2

代码:

#include <iostream>
#include <vector>
#include "Stopwatch.h"

static constexpr int N = 1000000000;

int main()
{
    std::vector<double> buffer;

    buffer.resize(10);

    for (auto& i : buffer)
    {
        i = 1e-100;
    }

    double k = 0;
    int h = 0; // removing this line and swapping the lines std::cout << "time = "... results in 3x slower code??!!

    Stopwatch watch;

    for (int i = 0; i < N; i++)
    {
        for (auto& j : buffer)
        {
            k += j;
        }
    }

    //std::cout << "time = " << watch.ElapsedMilliseconds() << " / " << k << std::endl;
    std::cout << "time = " << watch.ElapsedMilliseconds() << " / " << k << " / " << h << std::endl;

    std::cout << "Done...";
    std::getchar();

    return EXIT_SUCCESS;
}

秒表类:

#pragma once

#include <chrono>

class Stopwatch
{
private:
    typedef std::chrono::high_resolution_clock clock;
    typedef std::chrono::microseconds microseconds;
    typedef std::chrono::milliseconds milliseconds;

    clock::time_point _start;

public:
    Stopwatch()
    {
        Restart();
    }

    void Restart()
    {
        _start = clock::now();
    }

    double ElapsedMilliseconds()
    {
        return ElapsedMicroseconds() * 1E-3;
    }

    double ElapsedSeconds()
    {
        return ElapsedMicroseconds() * 1E-6;
    }

    Stopwatch(const Stopwatch&) = delete;
    Stopwatch& operator=(const Stopwatch&) = delete;

private:
    double ElapsedMicroseconds()
    {
        return static_cast<double>(std::chrono::duration_cast<microseconds>(clock::now() - _start).count());
    }
};

编辑问题以修复位置混乱的换行符后,并在地址中的地址前面添加分支目标标签jcc弄清楚代码实际上在做什么的说明,很明显循环明显不同。这movsd不在循环内重新排序;它是outside循环。

我决定编辑问题并在这里讨论它,而不是将这些内容留在问题中并在答案中更正它。我认为代码块足够长,以至于未来的读者会陷入试图跟踪代码的 4 个版本的困境,而且这并不能帮助有相同问题的人通过搜索引擎找到它。


快速版本保留k在寄存器中(xmm0),而慢速版本每次迭代都会重新加载/存储它。这通常表明编译器的别名分析未能证明事物不能重叠。

造成伤害的并不是额外的存储和负载本身,而是事实它通过存储转发延迟来延长循环携带的依赖链从一次迭代中的存储到下一次迭代中的加载。现代 Intel CPU 上的存储转发延迟约为 6 个周期,而现代 Intel CPU 上的存储转发延迟约为 3 个周期addsd(例如 Haswell)。这样就完美地解释了 3 倍加速的因素:

  • 当循环携带的依赖链为时,每次迭代 9 个周期addsd+ 存储转发
  • 当循环携带的依赖链正好是时,每次迭代 3 个周期addsd

See http://agner.org/optimize/ http://agner.org/optimize/有关指令表和微体系结构详细信息。还有其他链接x86 /questions/tagged/x86标签维基。


我不知道 MSVC 怎么没能证明这一点k不与任何内容重叠,因为它是一个本地地址,其地址不会转义该函数。 (它的地址甚至没有被占用)。 MSVC 在那里做得很糟糕。也应该只是xorps xmm0,xmm0在循环之前将其归零,而不是加载一些归零的内存。我什至不知道它在哪里将内存归零;我想这不是整个函数的汇编。

如果您使用 MSVC 的等效项进行编译-ffast-math,它可以向量化减少(用addpd),并希望有多个累加器。虽然有了这样一个tiny对于要循环多次的向量,非 4 倍数元素计数相当不方便。不过,循环开销在这里并不是问题;即使在以下情况下,循环携带的依赖链也占主导地位k保存在寄存器中,因为您的代码仅使用一个累加器。一addsd每 3 个时钟就为其他 insn 的运行留下了大量的时间。

理想情况下,允许关联 FP 数学重新排序将使编译器将其优化为k = N * std::accumulate(...);就像 @Ped7g 建议的那样,将数组的总和视为公共子表达式。


顺便说一句,有更好的方法来初始化向量:

而不是调整向量的大小(使用默认构造函数构造新元素)和then写入新的值,你应该做类似的事情

std::vector<double> buffer(10, 1e-100);   // 10 elements set to 1e-100

这可以确保汇编在存储您想要的值之前不会浪费时间存储零。我认为resize还可以将一个值复制到新元素中,因此您仍然可以声明一个空向量,然后调整它的大小。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

更改完全不相关的代码时,Visual Studio C++ 编译器生成的代码速度慢 3 倍 的相关文章

随机推荐