-march=native 有害的原因是什么

Question

我正在编写一个 C++ 程序来求解网络上的偏微分方程和代数方程。 Eigen 库承担了最大的部分工作，它通过 LU 分解求解许多稀疏线性系统。

由于性能总是很好，所以我尝试了一些选项。我正在使用

g++ -O3 -DNDEBUG -flto -fno-fat-lto-objects -std=c++17

作为与性能相关的编译器选项。然后我添加了 -march=native 选项并发现执行时间平均增加了大约 6%（由 gnu time 测试，每个配置的样本大小约为 10 次运行。两种设置几乎没有差异）。

这种观察的可能（或最好可能）原因是什么。

我猜 lscpu 的输出在这里可能有用，就是这样：

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              2
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           78
Model name:                      Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
Stepping:                        3
CPU MHz:                         800.026
CPU max MHz:                     3100.0000
CPU min MHz:                     400.0000
BogoMIPS:                        5199.98
Virtualization:                  VT-x
L1d cache:                       64 KiB
L1i cache:                       64 KiB
L2 cache:                        512 KiB
L3 cache:                        4 MiB

编辑：这里要求的是 cpu 标志：

vendor_id   : GenuineIntel
cpu family  : 6
model name  : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz

flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple pml
bogomips    : 5199.98
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual

Answer 1

使用 -march=native 时代码变慢的原因有很多，尽管这是非常特殊的。

也就是说，在您的特定上下文中，一种可能的情况是使用较慢的 SIMD 指令，或者更准确地说，不同的 SIMD 指令最终使程序变慢。实际上，GCC 使用像您这样的 x86 处理器上的 SSE 指令集使用 -O3 向量化循环（为了向后兼容）。使用 -march=native，GCC 可能会使用更高级和更新的 AVX 指令集（您的处理器支持，但许多旧的 x86 处理器不支持）对循环进行矢量化。虽然使用 AVX 指令可以加快程序速度，但在少数病态情况下并非总是如此（编译器启发式生成的代码效率较低，循环太小而无法利用 AVX 指令，missing/slower SSE 中可用的 AVX 指令、对齐、转换惩罚、energy/frequency 影响等）。

我猜你的程序是内存限制的，因此 AVX 指令不会让你的程序更快。

您可以通过使用 -mavx -mavx2 而不是 -march=native 手动启用 AVX 来确认这一假设，并查看您的性能问题是否仍然存在。我建议您使用 perf.

之类的工具仔细对您的应用程序进行基准测试

-march=native 有害的原因是什么

What are reasons for -march=native to be detrimental

c++

performance

gcc

eigen