What I've learned is that the fewer flags is the best path for any long lived project.

-O2 is basically all you usually need. As you update your compiler, it'll end up tweaking exactly what that general optimization does based on what they know today.

Because that's the thing about these flags, you'll generally set them once at the beginning of a project. Compiler authors will reevaluate them way more than you will.

Also, a trap I've observed is setting flags based on bad benchmarks. This applies more to the JVM than a C++ compiler, but never the less, a system's current state is somewhat random. 1->2% fluctuations in performance for even the same app is normal. A lot of people won't realize that and ultimately add flags based on those fluctuations.

But further, how code is currently layed out can affect performance. You may see a speed boost not because you tweaked the loop unrolling variable, but rather your tweak may have relocated a hot path to be slightly more cache friendly. A change in the code structure can eliminate that benefit.

▲

201984 an hour ago | parent [-]

What's your reason for -O2 over -O3?

▲

cogman10 an hour ago | parent | next [-]

Historically, -O3 has been a bit less stable (producing incorrect code) and more experimental (doesn't always make things faster).

Flags from -O3 often flow down into -O2 as they are proven generally beneficial.

That said, I don't think -O3 has the problems it once did.

	▲	sgerenser 29 minutes ago \| parent \| next [-]
		-O3 gained a reputation of being more likely to "break" code, but in reality it was almost always "breaking" code that was invalid to start with (invoked undefined behavior). The problem is C and C++ have so many UB edge cases that a large volume of existing code may invoke UB in certain situations. So -O2 thus had a reputation of being more reliable. If you're sure your code doesn't invoke undefined behavior, though, then -O3 should be fine on a modern compiler.
	▲	201984 an hour ago \| parent \| prev [-]
		Thanks

▲

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

You have to profile for your specific use case. Some programs run slower under O3 because it inlines/unrolls more aggressively, increasing code size (which can be cache-unfriendly).

	▲	grogers a few seconds ago \| parent [-]
		Yeah, -O3 generally performs well in small benchmarks because of aggressive loop unrolling and inlining. But in large programs that face icache pressure, it can end up being slower. Sometimes -Os is even better for the same reason, but -O2 is usually a better default.

▲

bluGill 31 minutes ago | parent | prev [-]

Most people use -O2 and so if you use -O3 you risk some bug in the optimizer that nobody else noticed yet. -O2 is less likely to have problems.

In my experience a team of 200 developers will see 1 compiler bug affect them every 10 years. This isn't scientific, but it is a good rule of thumb and may put the above in perspective.

	▲	macintux 7 minutes ago \| parent [-]
		Would you say that bug estimate is when using -O2 or -O3?