GCC Benchmarks At Varying Optimization Levels With Core i9 10900K Show An Unexpected Surprise

[sdack]

Without -march=native GCC optimizes the code for the generic oldest x86-64 CPU which is Athlon 64 from over 15 years ago. Quite expectedly the extended instruction set is not being used.

You're missing the point. The problem is that it shows with gcc 10, but it doesn't show with gcc 8 and 9. This is very likely a compiler regression.

[birdie]

Because many distributions and others just do "-O2" without "-march=native" which is why that level was tested that way.

Fedora uses -mtune=generic. You could at least use it. As for distros omitting this option, that's their fault.

You're missing the point. The problem is that it showswith gcc 10, but it doesn't show with gcc 8 and 9. This is very likely a compiler regression.

Or it might be possible that they found non-compliant x86-64 options which prevented the code from running on the oldest x86-64 CPUs and removed it.

Edit: I've gone ahead and filed a bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337

[bug77]

So, -O2 was run without -march=native, while -O3 used the option.

Sorry, Michael , it's hard to take your results seriously. Please retest while giving all the optimization levels comparable compilation flags.

Without -march=native GCC optimizes the code for the generic oldest x86-64 CPU which is Athlon 64 from over 15 years ago. Quite expectedly the extended instruction set is not being used.

And yet you can still see the elephant in the room: giant regression in gcc10.

Edit: beaten to the punch.

[rene]

well, I said for a while GCC is mostly compiling slower, not producing significantly different or slower binaries, also on other architectures like PowerPC and MIPS: https://www.youtube.com/watch?v=0iN-ynOvxUQ

[carewolf]

Fedora uses -mtune=generic. You could at least use it. As for distros omitting this option, that's their fault.

AFAIK -mtune=generic is the default, it just resets the CPU tuning after you have specified an -march argument

[carewolf]

Or it might be possible that they found non-compliant x86-64 options which prevented the code from running on the oldest x86-64 CPUs and removed it.

Highly unlikely. We test our binaries to see if they are truly portable using x86-64 emulation (the only way of testing it short of using 15+ year old CPUs), and haven't found any non-portable instructions in the default generated binaries.

[Steffo]

Very interesting results! Thx! I hope the GGC devs are fixing these regressions!

[pyler]

They reworked inliner thresholds for O2 in gcc 10 and now O2 sucks

they failed to fix compile time regressions by using better code / algoritms so they used a big hammer and destroyed inliner for O2 :/ And almost all linux software is compiled with O2 - ouch!

Michael, any results for branched clang 11 ? Your benchmarks helped a lot and some regressions were fixed before clang 10 final release thanks to your results.

[pyler]

hubicka - any chance to fix this madness with O2?

[pyler]

RIP linux kernel compiled with -O2