sz *_*ter 1 c++ performance gcc simd avx2
我正在学习和玩 SIMD 函数并编写了一个简单的程序，将它可以在1 秒内运行的向量加法指令的数量与普通标量加法进行比较。我发现 SIMD 在较低的优化级别上表现相对更好，而在较高的优化级别上表现得更差，我想知道我同时使用 MSVC 和 gcc的原因，这是同一个故事。以下结果来自Ryzen 7 CPU。我还在英特尔平台上进行了测试，也几乎是一样的故事。
#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%)
reinterpret_cast<uint32_t*>(&local)在循环让 GCC9在循环local 内存储/重新加载之后，创建了存储转发瓶颈。
这已经在 GCC10 中修复了；无需提交遗漏优化错误。 不要将指针投射到__m256i本地；它也违反了严格走样所以它是未定义行为，而不-fno-strict-aliasing即使GCC往往使得它的工作。（您可以指向__m256i*任何其他类型，但反之则不行。）
gcc9.3（您正在使用）正在循环内存储/重新加载您的向量，但将标量保存在寄存器中inc eax！
因此，向量循环在向量存储转发 plus 的延迟上成为瓶颈vpaddd，并且恰好比标量循环慢 8 倍多。他们的瓶颈是无关的，接近 1 倍的总速度只是巧合。
（标量循环大概在 Zen1 或 Skylake 上以每次迭代运行 1 个周期，以及 7 个周期存储转发加 1 来表示vpaddd正确的声音）。
它是由 间接引起的reinterpret_cast<uint32_t*>(&local)，要么是因为 GCC 试图原谅严格的别名未定义行为违规，要么只是因为您完全使用了指向本地的指针。
这不是正常的或预期的，但是内循环内的原子负载和 lambda 的组合可能使 GCC9 犯了这个错误。（请注意，GCC9和10重装地址的stopFlag从循环内的线程函数ARG，即使是标量，所以有已经有一些失败让事情在寄存器中。）
在正常用例中，每次检查停止标志时您将执行更多 SIMD 工作，并且通常您不会在迭代中保持向量状态。通常你会有一个非原子参数来告诉你有多少工作要做，而不是你在内部循环中检查的停止标志。所以这个错过选择的错误很少是一个问题。（除非即使没有原子标志也会发生？）
可在 Godbolt 上重现，显示-DUB_TYPEPUNvs. -UUB_TYPEPUNfor source 我曾经#ifdef使用你的不安全（和错过的选择触发）版本 vs. 一个安全的版本，从Fastest 方法手动矢量化洗牌，使用 AVX512 计算所有打包的 32 位整数的总和或 AVX2。（该手动 hsum 在添加之前不会变宽，因此它可能会溢出和换行。但这不是重点；使用不同的手动洗牌或_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
在我的英特尔 Skylake i7-6700k 上，对于每个线程数，我得到了预期的 800 +- 1%，使用 g++ 10.1 -O3 -march=skylake、Arch GNU/Linux、energy_performance_preference=balance_power（最大时钟 = 3.9GHz，任何活动核心数）。
标量循环和矢量循环具有相同数量的 uops 且没有不同的瓶颈，因此它们以相同的周期/迭代运行。（4，如果它可以保持这些地址 -> 停止标志负载的价值链在飞行中，则可能每个周期运行 1 次迭代）。
Zen1 可能不同，因为它vpaddd ymm是 2 uop 。但它的前端足够宽，可能仍然以每次迭代 1 个周期运行该循环，因此您也可能在那里看到 800%。
随着++loop取消注释，我得到〜267％ “SIMD速度”。在 SIMD 循环中有一个额外的 inc，它变成了 5 uop，并且可能会在 Skylake 上受到一些令人讨厌的前端影响。
-O0基准测试通常没有意义，它有不同的瓶颈（通常是将所有内容保存在内存中来存储/重新加载），并且 SIMD 内在函数通常在-O0. 尽管在这种情况下，甚至-O3在 SIMD 循环的存储/重新加载上遇到了瓶颈。
| 归档时间： |
|
| 查看次数： |
162 次 |
| 最近记录： |