AVX2 simd 在更高优化级别的标量性能相对较差答案

【问题标题】：AVX2 simd performs relatively worse to scalar at higher optimization levelAVX2 simd 在更高优化级别的标量性能相对较差
【发布时间】：2020-12-01 06:44:04
【问题描述】：

我正在学习和玩 SIMD 函数并编写了一个简单的程序，将它可以在 1 秒 内运行的向量加法指令的数量与普通标量加法进行比较。 我发现 SIMD 在较低优化级别的性能相对较好，而在较高的优化级别始终较差，我想知道原因我同时使用了 MSVC 和 gcc，这是同一个故事。以下结果来自 Ryzen 7 CPU。我还在 Intel 平台上进行了测试，情况也差不多。

#include <iostream>
#include <numeric>
#include <chrono>
#include <iterator>
#include <thread>
#include <atomic>
#include <vector>
#include <immintrin.h>
int main()
{
    const auto threadLimit = std::thread::hardware_concurrency() - 1; //for running main() 
    for (auto i = 1; i <= threadLimit; ++i)
    {
        std::cerr << "Testing " << i << " threads: ";
        std::atomic<unsigned long long> sumScalar {};
        std::atomic<unsigned long long> loopScalar {};
        std::atomic<unsigned long long> sumSimd {};
        std::atomic<unsigned long long> loopSimd {};
        std::atomic_bool stopFlag{ false };
        std::vector<std::thread> threads;
        threads.reserve(i);
        {
            for (auto j = 0; j < i; ++j)
                threads.emplace_back([&]
                    {
                        uint32_t local{};
                        uint32_t loop{};
                        while (!stopFlag)
                        {
                            ++local;
                            ++loop;  //removed this(see EDIT)
                        }
                        sumScalar += local;
                        loopScalar += loop;
                    });
            std::this_thread::sleep_for(std::chrono::seconds{ 1 });
            stopFlag = true;
            for (auto& thread : threads)
                thread.join();
        }
        threads.clear();
        stopFlag = false;
        {
            for (auto j = 0; j < i; ++j)
                threads.emplace_back([&]
                    {
                        const auto oneVec = _mm256_set1_epi32(1);
                        auto local = _mm256_set1_epi32(0);
                        uint32_t inc{};
                        while (!stopFlag)
                        {
                            local = _mm256_add_epi32(oneVec, local);
                            ++inc; //removed this(see EDIT)
                        }
                        sumSimd += std::accumulate(reinterpret_cast<uint32_t*>(&local), reinterpret_cast<uint32_t*>(&local) + 8, uint64_t{});
                        loopSimd += inc;
                    });
            std::this_thread::sleep_for(std::chrono::seconds{ 1 });
            stopFlag = true;
            for (auto& thread : threads)
                thread.join();
        }
        std::cout << "Sum: "<<sumSimd <<" / "<<sumScalar <<"("<<100.0*sumSimd/sumScalar<<"%)\t"<<"Loop: "<<loopSimd<<" / "<<loopScalar<<"("<< 100.0*loopSimd/loopScalar<<"%)\n";
    // SIMD/Scalar, higher value means SIMD better
    }
}

有了g++ -O0 -march=native -lpthread，我得到了：

Testing 1 threads: Sum: 1004405568 / 174344207(576.105%)        Loop: 125550696 / 174344207(72.0131%)
Testing 2 threads: Sum: 2001473960 / 348079929(575.004%)        Loop: 250184245 / 348079929(71.8755%)
Testing 3 threads: Sum: 2991335152 / 521830834(573.238%)        Loop: 373916894 / 521830834(71.6548%)
Testing 4 threads: Sum: 3892119680 / 693704725(561.063%)        Loop: 486514960 / 693704725(70.1329%)
Testing 5 threads: Sum: 4957263080 / 802362140(617.834%)        Loop: 619657885 / 802362140(77.2292%)
Testing 6 threads: Sum: 5417700112 / 953587414(568.139%)        Loop: 677212514 / 953587414(71.0174%)
Testing 7 threads: Sum: 6078496824 / 1067533241(569.396%)       Loop: 759812103 / 1067533241(71.1746%)
Testing 8 threads: Sum: 6679841000 / 1196224828(558.41%)        Loop: 834980125 / 1196224828(69.8013%)
Testing 9 threads: Sum: 7396623960 / 1308004474(565.489%)       Loop: 924577995 / 1308004474(70.6861%)
Testing 10 threads: Sum: 8158849904 / 1416026963(576.179%)      Loop: 1019856238 / 1416026963(72.0224%)
Testing 11 threads: Sum: 8868695984 / 1556964234(569.615%)      Loop: 1108586998 / 1556964234(71.2018%)
Testing 12 threads: Sum: 9441092968 / 1655554694(570.268%)      Loop: 1180136621 / 1655554694(71.2835%)
Testing 13 threads: Sum: 9530295080 / 1689916907(563.951%)      Loop: 1191286885 / 1689916907(70.4938%)
Testing 14 threads: Sum: 10444142536 / 1805583762(578.436%)     Loop: 1305517817 / 1805583762(72.3045%)
Testing 15 threads: Sum: 10834255144 / 1926575218(562.358%)     Loop: 1354281893 / 1926575218(70.2948%)

有了g++ -O3 -march=native -lpthread，我得到了：

Testing 1 threads: Sum: 2933270968 / 3112671000(94.2365%)       Loop: 366658871 / 3112671000(11.7796%)
Testing 2 threads: Sum: 5839842040 / 6177278029(94.5375%)       Loop: 729980255 / 6177278029(11.8172%)
Testing 3 threads: Sum: 8775103584 / 9219587924(95.1789%)       Loop: 1096887948 / 9219587924(11.8974%)
Testing 4 threads: Sum: 11350253944 / 10210948580(111.158%)     Loop: 1418781743 / 10210948580(13.8947%)
Testing 5 threads: Sum: 14487451488 / 14623220822(99.0715%)     Loop: 1810931436 / 14623220822(12.3839%)
Testing 6 threads: Sum: 17141556576 / 14437058094(118.733%)     Loop: 2142694572 / 14437058094(14.8416%)
Testing 7 threads: Sum: 19883362288 / 18313186637(108.574%)     Loop: 2485420286 / 18313186637(13.5718%)
Testing 8 threads: Sum: 22574437968 / 17115166001(131.897%)     Loop: 2821804746 / 17115166001(16.4872%)
Testing 9 threads: Sum: 25356792368 / 18332200070(138.318%)     Loop: 3169599046 / 18332200070(17.2898%)
Testing 10 threads: Sum: 28079398984 / 20747150935(135.341%)    Loop: 3509924873 / 20747150935(16.9176%)
Testing 11 threads: Sum: 30783433560 / 21801526415(141.199%)    Loop: 3847929195 / 21801526415(17.6498%)
Testing 12 threads: Sum: 33420443880 / 22794998080(146.613%)    Loop: 4177555485 / 22794998080(18.3266%)
Testing 13 threads: Sum: 35989535640 / 23596768252(152.519%)    Loop: 4498691955 / 23596768252(19.0649%)
Testing 14 threads: Sum: 38647578408 / 23796083111(162.412%)    Loop: 4830947301 / 23796083111(20.3014%)
Testing 15 threads: Sum: 41148330392 / 24252804239(169.664%)    Loop: 5143541299 / 24252804239(21.208%)

编辑：删除loop 变量后，在两种情况下都只留下local（参见代码中的编辑），结果仍然相同。

EDIT2：上面的结果是在 Ubuntu 上使用 GCC 9.3。我在 Windows (mingw) 上切换到 GCC 10.2，它显示了很好的缩放，见下文（结果是原始代码）。差不多可以断定是MSVC和GCC老版本的问题？

Testing 1 threads: Sum: 23752640416 / 3153263747(753.272%)      Loop: 2969080052 / 3153263747(94.159%)
Testing 2 threads: Sum: 46533874656 / 6012052456(774.01%)       Loop: 5816734332 / 6012052456(96.7512%)
Testing 3 threads: Sum: 66076900784 / 9260324764(713.548%)      Loop: 8259612598 / 9260324764(89.1936%)
Testing 4 threads: Sum: 92216030528 / 12229625883(754.038%)     Loop: 11527003816 / 12229625883(94.2548%)
Testing 5 threads: Sum: 111822357864 / 14439219677(774.435%)    Loop: 13977794733 / 14439219677(96.8044%)
Testing 6 threads: Sum: 122858189272 / 17693796489(694.357%)    Loop: 15357273659 / 17693796489(86.7947%)
Testing 7 threads: Sum: 148478021656 / 19618236169(756.837%)    Loop: 18559752707 / 19618236169(94.6046%)
Testing 8 threads: Sum: 156931719736 / 19770409566(793.771%)    Loop: 19616464967 / 19770409566(99.2213%)
Testing 9 threads: Sum: 143331726552 / 20753115024(690.652%)    Loop: 17916465819 / 20753115024(86.3315%)
Testing 10 threads: Sum: 143541178880 / 20331801415(705.993%)   Loop: 17942647360 / 20331801415(88.2492%)
Testing 11 threads: Sum: 160425817888 / 22209102603(722.343%)   Loop: 20053227236 / 22209102603(90.2928%)
Testing 12 threads: Sum: 157095281392 / 23178532051(677.762%)   Loop: 19636910174 / 23178532051(84.7202%)
Testing 13 threads: Sum: 156015224880 / 23818567634(655.015%)   Loop: 19501903110 / 23818567634(81.8769%)
Testing 14 threads: Sum: 145464754912 / 23950304389(607.361%)   Loop: 18183094364 / 23950304389(75.9201%)
Testing 15 threads: Sum: 149279587872 / 23585183977(632.938%)   Loop: 18659948484 / 23585183977(79.1172%)

【问题讨论】：

@AlexLarionov 我认为你犯了一个错误。与-O0 相比，-O3 的标量和 SIMD 都得到了改进，但相对于-O3 的标量指令，SIMD 指令的运行速度相对要慢得多（意味着标量改进更多，而 SIMD 改进更少）。
@harold 是的，之后看我的编辑。与具有loop 变量的原始代码相比，几乎没有区别。
您是否进行了分析以检查哪条指令似乎花费的时间最多？
@PeterCordes 当我一个小时左右前把它固定起来时，它实际上并没有。这是我的担忧之一。由于标量运行的迭代之间的原子检查，它可能不能。
@Mgetz：我想知道这一点，感谢您的检查。是的，产生 8 倍于 stopFlag 的读取次数将有效地算作优化读取；向量化就像展开然后卷成一个向量。我认为这可以解释-O2 与-O3 的区别，但这个问题实际上测试了-O0 调试模式。这不是我对“高er”优化的期望。你可以说-O0 并不是真正的“没有优化”，因为 GCC 总是在表达式中做一些事情，和/或这个短语没有意义，但是-O0 有不同的瓶颈。

标签： c++ performance gcc simd avx2

【解决方案1】：

reinterpret_cast<uint32_t*>(&local) 在循环让 GCC9 存储/重新加载 local 在循环之后，造成存储转发瓶颈。

这已经在 GCC10 中修复了；无需提交错过优化的错误。 不要将指针投射到 __m256i 本地；它也违反了严格的别名，所以 it's Undefined Behaviour 没有 -fno-strict-aliasing 即使 GCC 经常使它工作。 (You can point __m256i* at any other type, but not vice versa.)

gcc9.3（您正在使用）在循环中存储/重新加载您的向量，但将标量保存在inc eax的寄存器中！

向量循环因此成为向量存储转发延迟加上vpaddd 的瓶颈，而这恰好比标量循环慢 8 倍多。它们的瓶颈无关，接近 1 倍的总速度只是巧合。

（标量循环大概在 Zen1 或 Skylake 上每次迭代运行 1 个周期，7 个周期的存储转发加上 1 个 vpaddd 听起来差不多）。

这是由 reinterpret_cast<uint32_t*>(&local) 间接引起的，或者是因为 GCC 试图原谅严格别名未定义行为的违规行为，或者只是因为您完全采用了指向本地的指针.

这是不正常的或预期的，但是内部循环内的原子负载和可能的 lambda 的组合使 GCC9 犯了这个错误。（请注意，GCC9 和 10 正在从循环内的线程函数 arg 重新加载 stopFlag 的地址，即使对于标量也是如此，因此将内容保存在寄存器中已经有些失败。）

在正常用例中，每次检查停止标志时，您会做更多的 SIMD 工作，而且您通常不会在迭代中保持向量状态。通常你会有一个非原子参数告诉你要做多少工作，而不是你在内部循环中检查的停止标志。所以这个错过选择的错误很少成为问题。（除非即使没有原子标志也会发生？）

可重现的on Godbolt，显示-DUB_TYPEPUN 与-UUB_TYPEPUN 的源代码，其中我使用#ifdef 使用您的不安全（和错过的选择触发）版本与带有来自@ 的手动矢量化随机播放的安全版本987654324@。（该手动 hsum 在添加之前不会变宽，因此它可能会溢出和换行。但这不是重点；使用不同的手动 shuffle 或 _mm256_store_si256 到单独的数组，可以在没有严格混叠的情况下获得您想要的结果未定义的行为。）

标量循环是：

# g++9.3 -O3 -march=znver1
.L5:                                      # do{
        inc     eax                         # local++
.L3:
        mov     rdx, QWORD PTR [rdi+8]      # load the address of stopFlag from the lambda
        movzx   edx, BYTE PTR [rdx]         # zero-extend *&stopFlag into EDX
        test    dl, dl
        je      .L5                       # }while(stopFlag == 0)

矢量循环，使用 g++ 9.3，-O3 -march=znver1，使用您的 reinterpret_cast（即我的源代码版本中的 -DUB_TYPEPUN）：

# g++9.3 -O3 -march=znver1  with your pointer-cast onto the vector

 # ... ymm1 = _mm256_set1_epi32(1)
.L10:                                               # do {
        vpaddd  ymm1, ymm0, YMMWORD PTR [rsp-32]       # memory-source add with set1(1)
        vmovdqa YMMWORD PTR [rsp-32], ymm1             # store back into stack memory
.L8:
        mov     rax, QWORD PTR [rdi+8]                  # load flag address
        movzx   eax, BYTE PTR [rax]                     # load stopFlag
        test    al, al
        je      .L10                                # }while(stopFlag == 0)

... auto-vectorized hsum, zero-extending elements to 64-bit for vpaddq

但是有了一个安全的__m256i 水平和，完全避免了指向local 的指针，local 保留在寄存器中。

#      ymm1 = _mm256_set1_epi32(1)
.L9:
        vpaddd  ymm0, ymm1, ymm0             # local += set1(1),  staying in a register, ymm0
.L8:
        mov     rax, QWORD PTR [rdi+8]       # same loop overhead, still 3 uops (with fusion of test/je)
        movzx   eax, BYTE PTR [rax]
        test    al, al
        je      .L9

... manually-vectorized 32-bit hsum

在我的 Intel Skylake i7-6700k 上，对于每个线程数，我得到预期的 800 +- 1%，g++ 10.1 -O3 -march=skylake，Arch GNU/Linux，energy_performance_preference=balance_power（最大时钟 = 3.9 GHz，任何数量的内核处于活动状态）。

标量和向量循环具有相同数量的微指令并且没有不同的瓶颈，因此它们以相同的周期/迭代运行。（4，如果它可以保持这些地址 -> 停止标志负载的价值链，则可能在每个周期运行 1 次迭代）。

Zen1 可能不同，因为 vpaddd ymm 是 2 微秒。但它的前端足够宽，可能仍以每次迭代 1 个周期运行该循环，因此您也可能在那里看到 800%。

++loop 未注释，我得到约 267% 的“SIMD 速度”。在 SIMD 循环中增加一个额外的 inc，它会变成 5 uop，并且可能会受到对 Skylake 的一些讨厌的前端影响。

-O0 基准测试通常毫无意义，它有不同的瓶颈（通常存储/重新加载将所有内容保存在内存中），并且 SIMD 内在函数通常在-O0 处有很多额外的开销。尽管在这种情况下，即使是 -O3 在 SIMD 循环的存储/重新加载方面也遇到了瓶颈。

【讨论】：