GCC x86 Performance Hints (2012)

Post by jcranmer » Fri, Aug 21, 2020, 2:40 PM UTC

simias wrote: post #9

ilaksh wrote: post #3

It feels like they are actually trying to convince me to finally switch to Clang or something. I mean, I have actually still never used Clang, but even before this list, I was aware that there were quite a few gcc defaults that were ridiculous. But every gcc article is about how there are even more ways that gcc doesn't actually work sensibly unless you know the trick. I mean, why doesn't it say somewhere in the help…

I'm not sure I understand your argument. The optimizations here are: >"-Ofast" same as "-O3 -ffast-math" -ffast-math makes the compiler violate IEEE, it would make a very bad default. -O3 used to be potentially buggy and somewhat experimental, although I doubt that it's much of a practical problem these days. It still makes the code harder to debug though. Most build systems I'm aware of default to debug builds, so G…

Post by jhallenworld » Fri, Aug 21, 2020, 2:53 PM UTC

glouwbug wrote: post #2

-flto is great if your project is less than 15,0000 lines. Otherwise, -Ofast in conjunction with -flto creates a single threaded link time step that's longer than half a minute, and it only goes up from there

Post by xxpor » Fri, Aug 21, 2020, 3:04 PM UTC

btown wrote: post #10

vii wrote: post #4

Earlier quoted context omitted.

The gold linker and now lld can do LTO pretty fast across huge codebases: this breaks down the techniques used https://archive.fosdem.org/2019/schedule/event/llvm_lld/ Curious that Intel seems to recommend dynamic linking to get architecture specific libc function implementations. Dynamic linking has considerable overhead.

I’m curious why this is necessary nowadays. Why not just ship a multi architecture static libc that chooses implementation at runtime? Branch prediction should make that practically zero cost, and with cache sizes at all levels I doubt binary size would have an impact. Are there other reasons?

Post by bigdict » Fri, Aug 21, 2020, 3:36 PM UTC

jhallenworld wrote: post #13

glouwbug wrote: post #2

-flto is great if your project is less than 15,0000 lines. Otherwise, -Ofast in conjunction with -flto creates a single threaded link time step that's longer than half a minute, and it only goes up from there

-flto is great at the other end of the spectrum- tiny systems. With "-Os -lto", much unused code from newlib is deleted, allowing the rest to fit in a tiny Cortex-M0 system. In the old days, each function of the C library was in its own object file in the library, but these days this appears to not be the case. But -lto gives the same effect.

Post by simias » Fri, Aug 21, 2020, 3:52 PM UTC

jcranmer wrote: post #11

simias wrote: post #9

Earlier quoted context omitted.

I'm not sure I understand your argument. The optimizations here are: >"-Ofast" same as "-O3 -ffast-math" -ffast-math makes the compiler violate IEEE, it would make a very bad default. -O3 used to be potentially buggy and somewhat experimental, although I doubt that it's much of a practical problem these days. It still makes the code harder to debug though. Most build systems I'm aware of default to debug builds, so G…

> So that means that you tell the compiler to assume that SSE is available on the target. By default GCC outputs code that's compatible with the baseline, which is perfectly reasonable IMO. Same reason why -march=native is also not the default, it is assumed that you may want to ship your binaries to other computers. If your x86 computer was made after the US invaded Iraq, it supports SSE2 instructions.