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

如何解决-march=native 有害的原因是什么

我正在编写一个 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

解决方法

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

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

我的猜测是您的程序受内存限制，因此 AVX 指令不会使您的程序更快。

您可以通过使用 -mavx -mavx2 而不是 -march=native 手动启用 AVX 来确认此假设，并查看您的性能问题是否仍然存在。我建议您使用 perf 之类的工具仔细地对您的应用程序进行基准测试。