Why is -march=native used so rarely?

With most C/C++ compilers, there's a flag passable to the compiler, -march=native, which tells the compiler to tune generated code for the micro-architecture and ISA extensions of the host CPU. Even if it doesn't go by the same name, there's typically an equivalent option for LLVM-based compilers, like rustc or swiftc.

In my own experience, this flag can provide massive speedups for numerically-intensive code, and it sounds like it would be free of compromises for code you're just compiling for your own machine. That said, I don't think I've seen any build system or static compiler that enables it by default:

• Obviously, any command-line compiler executable that requires you to pass it doesn't use it by default.

• I can't think of any IDE that enables this by default.

• I can't think of any common build system I've worked with (cmake, automake, cargo, spm, etc.) that enables it by default, even for optimized builds.

I can think of a few reasons for this, but none of them are really satisfactory:

• Using -march=native is inappropriate for binaries that will be distributed to other machines. That said, I find myself compiling sources for my own machine much more often than for others, and this doesn't explain its lack of use in debug builds, where there's no intention for distribution.

• At least on Intel x86 CPUs, it's my understanding that using AVX instructions infrequently could degrade performance or power efficiency, since the AVX unit is powered down when not in use, requiring it to be powered up to be used, and a lot of Intel CPUs downclock to run AVX instructions. Still, it only explains why AVX wouldn't be enabled, not why the code wouldn't be tuned for the particular micro-architecture's handling of regular instructions.

• Since most x86 CPUs use fancy out-of-order superscalar pipelines with register renaming, tuning code for a particular micro-architecture probably isn't particularly important. Still, if it could help, why not use it?

Conservative

If you take a closer look at the defaults of gcc, the oldest compiler in your list, you'll realize that they are very conservative:

• By default, on x86, only SSE 2 is activated; not even SSE 4.
• The set of flags in -Wall and -Wextra has not changed for years; there are new useful warnings, they are NOT added to -Wall or -Wextra.

Why? Because it would break things!

There are entire development chains relying on those convenience defaults, and any alteration brings the risk of either breaking them, or of producing binaries that will not run on the targets.

The more users, the greater the threat, so developers of gcc are very, very conservative to avoid world-wide breakage. And developers of the next batch of compilers follow in the footsteps of their elders: it's proven to work.

Note: rustc will default to static linking, and boasts that you can just copy the binary and drop it on another machine; obviously -march=native would be an impediment there.

Masses Friendly

And in the truth is, it probably doesn't matter. You actually recognized it yourself:

> In my own experience, this flag can provide massive speedups for numerically-intensive code

Most code is full of virtual calls and branches (typically OO code) and not at all numerically-intensive. Thus, for the majority of the code, SSE 2 is often sufficient.

The few codebases for which performance really matters will require significant time invested in performance tuning anyway, both at code and compiler level. And if vectorization matters, it won't be left at the whim of the compiler: developers will use the built-in intrinsics and write the vectorized code themselves, as it's cheaper than putting up a monitoring tool to ensure that auto-vectorization did happen.

Also, even for numerically intensive code, the host machine and the target machine might differ slightly. Compilation benefits from lots of core, even at a lower frequency, while execution benefits from a high frequency and possibly less cores unless the work is easily parallelizable.

Conclusion

Not activating -march=native by default makes it easier for users to get started; since even performance seekers may not care for it much, this means there's more to lose than gain.

---

In an alternative history where the default had been -march=native from the beginning; users would be used to specify the target architecture, and we would not be having this discussion.

-march=native is a destructive flag. It makes the binary possible not compatible on a lot of hardware (basically any CPU that is not a direct descendent of the one used for compilation). It is simply too dangerous to enable this by default.

Another important thing to consider is that -march=native's main end use is optimization. The default optimization flag is -O0 (no optimization) so it wouldn't make sense from this perspective either to enable it by default.

You are thinking from the perspective of power user, but the main audience of a compiler tool chain is not power users, but rather developers.

Most developers have separate development machine and target production systems. In case of consumer applications, this target system is other people's machine with all the variances. Building for the most common denominator is a safe default because it reduces the chance of bugs that only occurs outside the developer's own machines.

Of course there are cases where developers know that they'll be developing an application for a single target machine with known architecture. But even in this case, most applications are not performance sensitive, so the safe option as a default still works good enough, while developers who are working performance sensitive application usually are more willing to spend time to tweak their build configurations.