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

21–30 of 37 posts

Re: GCC x86 Performance Hints (2012)

#21

Post by roblabla »

nicoburns wrote: post #14
btown wrote: post #10

Earlier quoted context omitted.

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?

> 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 security measure, see [0]). MacOS and Solaris are two other OSes where, if I understand correctly, syscall ABI is not guaranteed and must go through a common library. Go used to embed syscalls, and ran into a lot of problems because of this.

[0]: https://marc.info/?l=openbsd-tech&m=157488907117170&w=2

Re: GCC x86 Performance Hints (2012)

#23

Post by ilaksh »

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…

So maybe it can't be default bit like I said should be mentioned in the help under the optimization option along with some of those other things.

Re: GCC x86 Performance Hints (2012)

#24

Post by sp332 »

google234123 wrote: post #12
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

Google has FB do LTO on their large code bases.

FB?

Re: GCC x86 Performance Hints (2012)

#25

Post by voldacar »

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…

I get that openbsd is obsessed with security, but this still makes me a little sad. C is very old, and it should be possible to create programs and programming languages that have no idea what C is or what libc is. Forcing all programs to communicate with the OS via libc seems wrong

Re: GCC x86 Performance Hints (2012)

#26

Post by kjs3 »

xxpor wrote: post #15
btown wrote: post #10

Earlier quoted context omitted.

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?

The L1 icache on most Arm chips is still fairly tiny. For example on the Snapdragon 865, it's only 64k. An i7-8700k (already 3 years old) on the other hand has 192k.

That's pretty meaningless. The effect of cache is very processor and ISA specific and has a log tail of value (as in, depending on the processor, X amount of cache may get you a 50% speedup, but 2 times X might only give you 60% so is the cost/benefit trade-off worth it). It's plausible that the i7 needs 3 times the cache to get the same benefit and the 64k in the 865. N.B. I don't know for sure that that is the case.

Re: GCC x86 Performance Hints (2012)

#27

Post by rndgermandude »

canarypilot wrote: post #8
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…

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 se…

Exactly. What you do not want to happen is that your program crashes with fancy "illegal instruction" errors on older CPUs that do not have the newest fancy features yet, but are still in use by a large chunk of your (paying) users.

Performance critical programs usually deal with that by either providing multiple builds targeting different CPU features/CPUs, or let the user compile themselves from source with the right flags, or have CPU runtime detection and provide alternative versions of a few important performance critical functions for different CPU feature sets (e.g. browsers, ffmpeg, glibc, various VMs/runtimes like Java Hotspot or dotnet, do that) while the majority of code is still compiled for a lowest common subset of CPU features.

Of course, languages that run on (usually) JIT-ed VMs/runtimes have a bit of an advantage here, as the actual machine code is generated from source code or byte code only at runtime, at which point it is clear what kind of CPU is underneath the program. They can - but not always do - implement optimized JITting depending on the CPU features. (of course, every language/VM/runtime comes with its own set of pros and cons and there is no silver bullet).

To make matters even more complicated: compiling code to use the newest CPU features or newest optimization techniques will not mean it will actually run faster. E.g. AVX512 may actually slow down your code (when multi-threaded) on many CPUs[1]. Or heavily "optimized" code may become larger in machine code, to the point where your "unoptimized" code may run faster because it fits in the CPU cache(s) properly while the "optimized" version does not. "-Os" optimized code may run faster than "-Ofast" optimized code for this matter. Or it may not. Depending on the actual code.

I remember compiling ffmpeg and libx264 myself a bunch of years ago, with the "best" flags for my system, starting with "-march=" and "-Ofast" of course, thinking I am a tough skillful super geek now. Imagine my surprise when I tested the performance against a default ffmpeg build and my optimized build was 2-5% slower.

[1] https://blog.cloudflare.com/on-the-dangers-of-intels-frequen...

Re: GCC x86 Performance Hints (2012)

#28

Post by roblabla »

voldacar wrote: post #25
roblabla wrote: post #21

Earlier quoted context omitted.

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

I get that openbsd is obsessed with security, but this still makes me a little sad. C is very old, and it should be possible to create programs and programming languages that have no idea what C is or what libc is. Forcing all programs to communicate with the OS via libc seems wrong

On one hand, from an idealistic point of view, I agree, and am a very, very big believer of having actual, carefully designed ABIs for kernel (and inter-process) communications.

On the other hand, the structures required to do syscalls via libc/kernel32 are generally simple enough that it's not a huge deal, and the difference between doing a raw syscall and doing a function call is unlikely to actually matter.

Fun fact/pet peeve: on android, if you want to communicate with most services, you need to go through Binder. While the low-level Binder ABI is stable, the services written on top of it aren't, and often change in backwards-incompatible ways. This includes core services like SurfaceFlinger (necessary to draw on the screen). This means that it's generally impossible to create purely native software on android - you always have to call into Java to talk to those services.

Re: GCC x86 Performance Hints (2012)

#30

Post by cozzyd »

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.

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