GCC x86 Performance Hints (2012)
software.intel.com
GCC x86 Performance Hints (2012)
1–10 of 37 posts
Re: GCC x86 Performance Hints (2012)
#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
Re: GCC x86 Performance Hints (2012)
#3It 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 next to the optimization stuff that you might want to consider specifying the architecture?
Re: GCC x86 Performance Hints (2012)
#4-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
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.
Re: GCC x86 Performance Hints (2012)
#5It 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…
To be fair, it is from 2012
Re: GCC x86 Performance Hints (2012)
#6In my .bashrc I use
export CFLAGS='-O2 -march=native -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables'
Re: GCC x86 Performance Hints (2012)
#7It 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…
clang also doesn't assume -march=native - just like gcc it makes binaries that can run on machines of the same architecture rather than specialising to the current processor's features.
You can see the flags it's using by comparing
clang -E -v - &1
clang -march=native -E -v - &1
+sse4.2 -target-feature +avx2 -target-feature +fxsr -target-feature -wbnoinvd -target-feature +sse -target-feature +lzcnt -target-feature +pclmul -target-feature -prefetchwt1 -target-feature +f16c -target-feature +ssse3 -target-feature -sgx -target-feature -shstk -target-feature +cmovRe: GCC x86 Performance Hints (2012)
#8It 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…
Clang works much the same way by default. All compilers have to pick a baseline, and assuming it is arch_of(your_core) is a recipe for disaster if you are compiling on your high-end machine for release to a broad user base.
For many users of GCC the intended user base will be “the same as my current distribution” and so GCC can be configured using —-with-{cpu, arch, schedule, tune} depending on the architecture to set a default in line with user/distro expectations.
Re: GCC x86 Performance Hints (2012)
#9It 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 GCC is not really unique in that regard.
>"-flto" enable link time optimizations
Those optimizations are typically quite expensive and can backfire in some scenarios. Link time optimizations are relatively novel, at least within the timeframe of GCC. I'm sure they'll be enabled by default some day, but GCC has to be conservative.
>"-mfpmath=sse" enables use of XMM registers in floating point instructions (instead of stack in x87 mode)
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.
>"-funroll-loops" enables loop unrolling
From GCC's own docs:
"This option makes code larger, and may or may not make it run faster."
Loop unrolling is tricky, because it gets rid of branches but also increases the size of the code and therefore the pressure on the icache. In some scenarios it's possible that the looping code run faster than the linear version if it saves on cache misses.
Given that there are tradeoffs involved, it's also reasonable to let the user decide to enable this optim.
I work with C a lot and IMO the only default in GCC that's truly bad is that it doesn't have -Wall by default.
Re: GCC x86 Performance Hints (2012)
#10-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
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?