GCC 4.9 vs. 5.3 vs. 6.0 Compiler Benchmarks On Debian 8.4

[geearf]

I mentioned Phoronix benchmarks because of your claim that O3 "do not always deliver better end result". The fact is that O3 consistently delivers the best performance, sometimes on par with some unpredictable other optimisation level.

Hmm I am not sure, even if that link I see at times O2 winning over O3.
That's pretty much what I got from a quick search: O3 should yield faster binaries, but maybe also bigger ones, and hence running them may not always be faster after all. (Some mentioned that PGO should help with that issue, but I have not looked into that).

[trifud]

Michael, can you test Intel C++ Compiler against GCC?

[wagaf]

Hmm I am not sure, even if that link I see at times O2 winning over O3.
That's pretty much what I got from a quick search: O3 should yield faster binaries, but maybe also bigger ones, and hence running them may not always be faster after all. (Some mentioned that PGO should help with that issue, but I have not looked into that).

Winning in compilation time, not performance.

[geearf]

Winning in compilation time, not performance.

I see.

[SaucyJack]

It can make some packages misscompile - they have hidden flaws. Which sometimes show later. And usually requires many hours of chasing bugs through many of already installed packages. And final speed gain with -O3 can still be _negative_ in the end. I have IIRC 1200+ packages on my workstation machine and I remember having quite a few exceptions that had to be compiled with tweaked C/XX/LD/FLAGS.

It clearly shows that you don't have a clue what you are talking about. If it was such no-brainer, it would really be a default option on gcc and diistros like Gentoo couldn't wait to demand it as a default option. But they are not, for good reason - it simply is not worth the effort in the end in their case. Each such breakage would mean new bugs, each bug would mean that much extra man-hours on chasing it and, more importantly, they tend demand work from several teams ( like the team, supporting package X has to cooperate with teams, responsible for libraries Y and Z etc).

So in practice, with any deviations from "standard" -O2 and especially with "-flto" you are on your own.

I never particularly cared for running to flocks like sheeps and doing things simply because Intel/whoever is doing something in some way. Intel is so loaded with $$$ that they could hire Shaolin monks to do some parts of compile by hand on papyrus with beautifull calligraphy jus for fun of it. This doesn't mean that should do it, too.

To be so sure of yourself and yet so disconnected from reality. How do you do it? You must have a position somewhere, academia maybe?

"It can make some packages misscompile" - is that right? Show me one.

"So in practice, with any deviations from "standard" -O2 and especially with "-flto" you are on your own." - -O3 has been standard for me for quite a while so, your definition of standard is drastically different. LTO is a different beast entirely.

"Gentoo couldn't wait to demand it as a default option." ??? this is Gentoos biggest claim to fame (besides maybe openRC). Compile everything as -march=native -O3.

"It clearly shows that you don't have a clue what you are talking about." Quite the opposite. I have more than enough physical proof than -O3 works flawlessly. In addition we have Intel's Clear linux and Gentoo also proving it every day. In fact the only optimization I've ever had an issue with was one out of -O2 one time. You just keep clinging to your superstitions guy and I'll be over here using -O3.

[Brane215]

"It can make some packages misscompile" - is that right? Show me one.

I don't feel like seaching through log files just to please you.

"Gentoo couldn't wait to demand it as a default option." ??? this is Gentoos biggest claim to fame (besides maybe openRC). Compile everything as -march=native -O3.

Again, it would help if you could refrain from talking through your ass. Here is quote from their AMD64 Installation Manual/Configuring compile options:

A second one is the -O flag (that is a capital O, not a zero), which specifies the gcc optimization class flag. Possible classes are s (for size-optimized), 0 (zero - for no optimizations), 1, 2 or even 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). -O2 is the recommended default. -O3 is known to cause problems when used system-wide, so we recommend to stick to -O2.

[ormaaj]

-O3 is a pretty big collection of options that do different things. You can't really speak generally about it. I haven't been able to reproduce said issues with system-wide -O3 usage. If there are problems I try to narrow it down to a specific option.