Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC x86 Performance Hints (2012)

software.intel.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: GCC x86 Performance Hints (2012)

#31

Post by moonchild »

roblabla wrote: post #21
nicoburns wrote: post #14

Earlier quoted context omitted.

> Are there other reasons? I think some systems don't have a stable kernel interface. The system-provided libc is that interface. On Linux I believe that this is possible (and fairly common using the MUSL libc), but that glibc doesn't support static linking and many people want to use glibc for performance and compatibility reasons.

> I think some systems don't have a stable kernel interface. The system-provided libc is that interface. In fact, a lot of systems don't have a stable kernel interface, Linux is the exceptions here. In Microsoft Windows, one must link against Kernel32.dll to communicate with the kernel. On OpenBSD, the libc provides the stable syscall interface (and in fact the kernel will refuse syscalls from outside the libc as a s…

> In Microsoft Windows, one must link against Kernel32.dll

Not kernel32, but ntdll.

FreeBSD is another OS that provides a stable kernel ABI.

Re: GCC x86 Performance Hints (2012)

#32

Post by jcranmer »

cozzyd wrote: post #30
jcranmer wrote: post #11

Earlier quoted context omitted.

> 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.

It's also possible someone may prefer the 80-bit intermediate precision of the x87 registers. I guess.

long double in either x87 or SSE mode will force the use of 80-bit fp values.

Re: GCC x86 Performance Hints (2012)

#33

Post by gnufx »

Supersaiyan_IV wrote: post #16

This article is way too outdated. Also, who the heck uses -flto on GCC 4.7.1? LTO is experimental in GCC 4.7.1 and will make any application nigh-impossible to debug. Here's something more relevant to modern times: http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inte...

Turning on LTO in Fedora hasn't been entirely painless despite SUSE's pioneering.

Re: GCC x86 Performance Hints (2012)

#34

Post by gnufx »

vii wrote: post #4
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

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.

Dynamic linking has considerable advantages in the facilities it provides, which seem to outweigh any efficiency concerns, e.g. in HPC.

Re: GCC x86 Performance Hints (2012)

#35

Post by gnufx »

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…

> >"-Ofast" same as "-O3 -ffast-math"

That depends on the language and the GCC version.

> -ffast-math makes the compiler violate IEEE, it would make a very bad default.

Yes, but unfortunately it's the Intel default, which contributes to some of the compiler mythology.

Regarding unrolling, you usually do want it in numeric loops, and -O3 unrolls (and jams) as -fopt-info shows.

Re: GCC x86 Performance Hints (2012)

#36

Post by glouwbug »

abra529 wrote: post #22
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

> 15,0000 lines Did you mean 150,000 or 15,000?

15,000, because I'm too poor to buy a new laptop

Re: GCC x86 Performance Hints (2012)

#37

Post by simias »

gnufx wrote: post #35
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…

> >"-Ofast" same as "-O3 -ffast-math" That depends on the language and the GCC version. > -ffast-math makes the compiler violate IEEE, it would make a very bad default. Yes, but unfortunately it's the Intel default, which contributes to some of the compiler mythology. Regarding unrolling, you usually do want it in numeric loops, and -O3 unrolls (and jams) as -fopt-info shows.

>That depends on the language and the GCC version.

I was quoting TFA verbatim. I actually never use -Ofast myself, beyond -O3 I tend to use the individual flags manually, checking wit benchmarks that it makes a difference.

>Yes, but unfortunately it's the Intel default, which contributes to some of the compiler mythology.

I didn't know that. I guess Intel is extremely performance-oriented and doesn't really care for portability so it makes some sense for them to do that.

>Regarding unrolling, you usually do want it in numeric loops, and -O3 unrolls (and jams) as -fopt-info shows.

Sure but that's to my point: the default optims for -O3 are fairly aggressive already. Unless you're writing code where performance is absolutely critical you'll probably be do just fine just remembering to pass "-Wall -O3" to GCC and that's it. Actually for most of my code where I want good performance but I'm not counting individual clock cycles I tend to default to -O2 which gives you most of the performance benefits with more conservative and easier to debug optimizations.

And for cases where you need to go beyond -O3 you'll probably have to write some benchmarking code before you can decide which additional option to use. At least, in my experience.

Post reply on HN