O3 versus O2

[Cossins]

Hi there!
I am sure this has been discussed before, but due to the annoying nature of the Search-function (e.g. not returning any results if one of the keywords contains less than 3 or 4 letters), I was unable to find satisfying answers...

What I want to hear about is people's experience on which is the best CFLAG choice, performance-wise. O2 or O3.

Theoretically, O3 should produce the most responsive binaries, but I have heard rumours that some things can actually be slower because of the heavy loop-unrolling and extra assembly calls here and there.

Also, has anyone noticed that GCC 3.3.1 is now in ~x86? That is kinda sweet...

- Simon

[OddFox]

I havn't done any rough bechmarks myself, but O3 is quite a gamble when it comes to optimization. I'm running an O3 system right now, and it seems alright, but that might just have something to do with my processor and 512MB SDRAM, since O3 is supposed to be heavy on the memory at times.

It's generally safer to go with O2, since it's almost always faster than the simple optimizations and at times faster than O3. I've never used Os, myself, but it would be interesting... I'm using about 5GB with a completely (Well, almost) merged system, KDE, GNOME, Flux, games, etc. I don't think I'll be adding anymore proggies in a while, just testing kernels for responsiveness and performance.

Anywho, I would say use O2, unless you've got a bunch of RAM like I do (And most others here).

[Cossins]

Yeah, I know... I have 768 Mb DDR2700 RAM, so that's not really an issue...

I just want to know: Which flag makes the most responsive system overall? (before I recompile glibc with gcc 3.3.1...)

- Simon

[Kihaji]

The way I always looked at it:

O2 optimizes for size
O3 for speed.

[Lovechild]

The way I always looked at it:

O2 optimizes for size
O3 for speed.

Then how does your flawed theory explain away Os ?

[thomas001]

ok...a standard answer:

RTFM!!!!!!!!!!!!!!!!!!!!!!!!!

http://gcc.gnu.org/onlinedocs/gcc-3.3.1 ... %20Options

[Cossins]

ok...a standard answer:

RTFM!!!!!!!!!!!!!!!!!!!!!!!!!

http://gcc.gnu.org/onlinedocs/gcc-3.3.1 ... %20Options

Believe me, I know that... Why does everyone assume that I am a n00b?

I wanted to know which optimization is actually the most efficient...

- Simon

[pilla]

I wanted to know which optimization is actually the most efficient...

- Simon

If somebody knew, the other optimization flags probably would not even exist

Truth is that it depends on the programs you are compiling and in the inputs these programs will use.

[()]

I would think it is very dependent on the implementation of GCC, and it's particular quirks. From what I remember Scott Ladd did an indepth comparison of combinations of optimization flags, where a combination of -O1 with some other flags did best? When it comes to Intel's ICC I've never heard of any advice to turn down optimizations. Its probably down to the engineers' understanding of optimization techniques. Of course, if your system is sparse on cache or memory you might want to optimize for space instead of speed.

[Kihaji]

The way I always looked at it:

O2 optimizes for size
O3 for speed.

Then how does your flawed theory explain away Os ?

From the site:
O2 - "Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. "

O3 - "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options. "

Which to me implies the space-speed consideration is not used. Hence O2 is more size conscience than O3.

Os is a step below O2 speed wise, but increases the space savings.

Does that satisfy you? Or would you like to stick your foot deeper into your mouth?

[robmoss]

Okay, look at it like this.

You have two cars, and two roads. One road is in a completely straight line and is nice and wide and flat. Another is one of those roads like you find in North Wales (where I live) - about 7 feet wide, grass up the middle and covering walls on either side, and a near-hairpin corner at least every 100 yards.

Your two cars are a Jaguar XJ220 and a Caterham R500 Superlight. The XJ220 will hit 220mph on the long, flat, wide straight road and going at only 140mph the Caterham will be left for dead. But on the twisty, turny road, the Caterham can go almost flat out pretty much for the entire duration, whereas the XJ220, being about 6 times heavier, will have to slow down hugely for all of the corners and won't get back up to speed nearly as quickly.

Now, extend the analogy so that you still only have two cars, but in between the two roads you have an billion other roads as well, each of intermediate and varying twistiness, flatness and width.

-O2 and -O3 are your cars and the roads are the programmes you're compiling. Which is the faster car along a given road? The answer doesn't exist: it depends on the road. And if you don't know what the road is like, the only way to decide for sure is to test it.

So, your answer? Well, there isn't one, but if you wanted to try to get somewhere near to one, the best thing you can do is to test each individual package, benchmark it to death having compiled it once with -O2 and once with -O3, and see what is the best for each package. Feasible? Well, no, not really.

So the only true answer is: guess. I, personally, guessed at -O3, but only because I trust the GCC developers to improve the general performance of their flagship optimization over time.

[robmoss]

GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff.

A space-speed tradeoff is one where either space will be sacrificed for speed, or speed will be sacrificed for space. So -O2 does not optimize for size. It merely creates code of a similar size to unoptimized code. -O2 optimizes for speed as much as possible whilst not increasing size.

-O3, as it says, optimizes purely for speed of execution, so space considerations are not taken into account at all.

-Os, as the manual says, optimizes like -O2, except that it turns on all optimizations that save space.

So: -Os optimizes for size but not speed, -O3 optimizes for speed but not size, and -O2 optimizes for speed without interfering with code size.

[MJN222]

The way I always looked at it:

O2 optimizes for size
O3 for speed.

Then how does your flawed theory explain away Os ?

From the site:
O2 - "Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. "

O3 - "Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options. "

Which to me implies the space-speed consideration is not used. Hence O2 is more size conscience than O3.

Os is a step below O2 speed wise, but increases the space savings.

Does that satisfy you? Or would you like to stick your foot deeper into your mouth?

Let's try to keep this civil guys, we don't need any flamewars here. What I post below is my interpretation of the explanation from the gcc man page (no I don't have tons of benchmarks for you). If anyone disagrees with my interpretation of the man page, feel free to respond and please include your reasons for disagreeing with me, but childish responses need not apply.

*dons flame retardant suit*

O3 optimizes for speed without regard to size at all - your executables will take up more space with this, but (hopefully) will be faster. (Most likely, please no pathological counter examples)

O2 optimizes for speed as much as possible - without actually increasing size dramatically (i.e. no loop-unrolling, inline functions, etc). However, it makes no claim to actually have any sort of space savings, so I don't agree that it optimizes for space, however it doesn't shoot itself in the foot either. Most likely a nice balance is achieved.

Os is similar to O2, but is borderline psycho about not increasing size, and even does some stuff to decrease size.

And now I'll duck out and if you two want to continue baiting each other, feel free. I always wanted to jump in the middle of a flame war

[pilla]

Does that satisfy you? Or would you like to stick your foot deeper into your mouth?

Would you like to read the guidelines? This is a good example of sentence that is not welcome in the forums.

[jstubbs]

K... I'm an O2 guy. I was an O3 guy but changed due to file sizes. In terms of actual running of application, I notice no difference. There's probably a bit here and there but none noticable to me. I haven't tried Os but, looking at what optimizations are turned off, I'm guessing there would be a slight noticable decrease in speed.

The reason I moved to O2? Two reasons: compile time and loading time. I'm running a laptop with a 5600RPM hard drive - the executable size seems to make quite a difference. Compile time also seems to have decreased a fair bit although I haven't done any benchmarks... yet...

Jason

[LockeAverame]

the filesize difference isn't as much, it's about 1% and this is nothing you should worry about, the more problematic thing is the cache on the processor. if you are unrolling loops and inligning functions than your cache will fill up with unlooped loops and functions, they will be executed faster but your processor than has fewer cache for data backup.
if your processor has a lot cache than mostly -O3 will be faster, except that a program uses many variables which it uses nearly randomly, because the processor mostly caches data which is in the near addressspace (mostly functions and variables next to the executing function are near in addressspace).
programs which use loops heavily could gain a big performancegain from -O3, but this is mostly theoretical (no one uses so much loops with nearly invariant data). it depends on the L1 and L2 caches (maybe L3 but seldom) of your processor and the programs u use, which flag is faster, i prefer -O3 because the difference to -O2 is not very big if it comes to a performancedecrease, but the performanceincrease by -O3 can be quite big.

[fishhead]

It mostly comes down to code cache size, I would think. Some options that increase code size will make the code go slower because the code in question won't fit entirely in the L1 cache and when the code isn't in cache, you'll have to get it from L2 or memory (maybe 20 or 200 cycles, respectively). I think this is a bigger problem for the Pentium4 then for 2/3, the PentiumM or any of the Athlons. The Pentium 4's I-cache only holds about 4,000 instructions and the P4 takes a big performance hit when instructions aren't in the I-cache. For the P4, size is a big issue.

[ebrostig]

If you really want the fastest, most optimized code and are using an Intel Processor, I would recommend emerging icc and setting the USE flag icc. This will make Portage use icc if it is possible.

You can also try to set CC=icc and emerge the program in question after installing the Intel C compiler.

There are a lot of builds that can not use it, but those who can benefit seriously from it.

(Oracle 9i on Linux is compiled completly with icc)

Erik

[()]

According to digit-life ICC even beats GCC when it comes to AMD Opteron :] A lot less packages than I'd like compile with it though (from what I've tried) :\

[Cossins]

Can ICC coexist with GCC without problems? And will packages that cannot be compiled with ICC automatically switch to GCC? What about C++, can ICC handle that?

- Simon

[fishhead]

What about C++, can ICC handle that?

Yea, except it's not icc, but icpc.