Why is -march=native used so rarely?

gcc clang compiler-optimization

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?

People generally like their compiled code to run on machines other than the one it was compiled on.

I think Gentoo users use it all the time. Other than that - doesn't give you that much most of the time, binaries cannot be used on other machines. Don't forget that you are probably dynamically linking with other libs that might not be tuned, so optimizing your app like that might give you nothing.

This “opinion-based” reason was misapplied to this question. As the text notes, that closure reason is for questions whose answers are likely to be “almost entirely based on opinions.” This is not a contentious issue, and the facts about using -march=native would be useful to present. It ought to be reopened.

This question would be better suited to a discussion forum

@interjay: A purpose of Stack Overflow is to create a repository of questions and answers to provide information for others seeking in the future, not merely to provide information to one person asking a question.

Matthieu M.

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.

How do i request all those wonderful warnings without calling each one by name?

@L29Ah: Using Clang, you can use -Weverything. Using gcc, you have to enable them one at a time -- there are a few families of 2-3 warnings, but not order of magnitude improvements.

bolov

-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.

What make it dangerous ? "The default optimization flag is -O0 (no optimization) so it wouldn't make sense from this perspective either to enable it by default." ? Is there a law that says the default optimization flag must be -O0

The reasoning about -O0 doesn't make sense; -march=native has no effect with -O0, so there's no reason not to activate it by default, and it would still benefit any other optimization level.

@MatthieuM. my point is this: with -O0 you basically don't care about optimizations. Since the default is "I don't care about optimization" why would a flag that mainly is used for optimization be enabled in default?

@bolov: It could be enabled by default when you ask for optimizations, no?

@bolov: I think you misunderstood my comment. My point is that there is ALWAYS an architecture specified, regardless of the optimization level. After all, even at -O0, the compiler needs to emit assembly instructions for a specific CPU family. For -O0, whether -march=native or -march=<generic> is the default still specifies the same family, so both are perfectly compatibly with -O0; and whenever another optimization level is specified, -march=native is beneficial to performance. So, for me, the fact that -O0 is the default doesn't matter for -march's default.

Lie Ryan

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.

Why is -march=native used so rarely?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US