> Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity.

Perhaps you can see how there are some assumptions baked into that statement.

What assumptions would that be?

Shipping anything built with -march=native is a horrible idea. Even on homogeneous targets like one of the clouds, you never know if they'll e.g. switch CPU vendors.

The correct thing to do is use microarch levels (e.g. x86-64-v2) or build fully generic if the target architecture doesn't have MA levels.

▲

tempest_ 17 minutes ago | parent [-]

I build on the exact hardware I intend to deploy my software to and ship it to another machine with the same specs as the one it was built on.

I am willing to hear arguments for other approaches.

	▲	eqvinox 12 minutes ago \| parent [-]
		I'm willing to hear arguments for your approach? it certainly has scale issues when you need to support larger deployments. [P.S.: the way I understand the words, "shipping" means "passing it off to someone else, likely across org boundaries" whereas what you're doing I'd call "deploying"]

▲

PufPufPuf an hour ago | parent | prev | next [-]

The only time I used -march=native was for a university assignment which was built and evaluated on the same server, and it allowed juicing an extra bit of performance. Using it basically means locking the program to the current CPU only.

However I'm not sure about -O3. I know it can make the binary larger, not sure about other downsides.

	▲	hmry 40 minutes ago \| parent [-]
		-O3 also makes build times longer (sometimes significantly), and occasionally the resulting program is actually slightly slower than -O2. IME -O3 should only be used if you have benchmarks that show -O3 actually produces a speedup for your specific codebase.

▲

izacus an hour ago | parent | prev [-]

Not assumptions, experience.

I fully concur with that whole post as someone who also maintained a C++ codebase used in production.