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

New optimizations for X86 in upcoming GCC 5.0

software.intel.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: New optimizations for X86 in upcoming GCC 5.0

#31

Post by yoklov »

bluecalm wrote: post #28
e12e wrote: post #16

Does anyone know if -O3 (or -O2?) -march=native should be enough to get reasonable optimization for running on the same cpu as the gcc host? Or are one better off tweaking options manually (note, I know that knowing the details of how gcc works will always be better than not -- I'm just wondering if -march=native is currently considered stable/"good enough" from reasonable value of "enough" ;-)

I remember that -flto sometimes adds few %'s to overall speed. If you are doing a lot of floating point math you can check various modes. First try is always -Ofast which turns on -ffast-math flag. From the gcc page: -ffast-math Sets -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range. This option causes the preprocessor macro __FAST_MATH__…

`-ffast-math` is a double-edged sword. It can frequently optimize away stuff like NaN checks and the like, breaking code that uses NaN as a missing value. This, specifically, has bitten me before, but there are certainly other areas that it can bite you.

OTOH it gives the compiler to do a great deal of algebraic simplifications, including expression reordering. This probably will bring what the compiler can actually do more in line with what you think it should be able to do.

Basically, you need to test with it on if you're going to use `-ffast-math`. You might also have good luck with turning on a subset of the flags. For example, IIRC in the project with the NaN checks, using all of them except `-ffinite-math-only` fixed the problem in this case.

Some of them are obvious to turn on though. `-fno-math-errno` should be the default for most programs, if you ask me. I've never seen anybody check `errno` to see if their call to, e.g. `sqrt`, was invalid, and I hope I never do.

Re: New optimizations for X86 in upcoming GCC 5.0

#32

Post by vardump »

livemusic wrote: post #22

Only loosely related, but I'm curious: What compiler optimizations have the biggest impact on scientific / floating point computation? Integer (audio/image) ops? With modern CPUs performing speculative execution, register renaming, and all the other magic they do, the CPU is acting like an optimizer in its own right. x64 is mostly just a byte code that gets JIT compiled at runtime. I'd be interested in seeing how muc…

This depends entirely on the specific code you're talking about. If the compiler finds out a specific optimization is applicable for a certain block of code, then it uses it.

So your question cannot be answered. Only possible answer is "it depends". Another guess: "From nothing to an order of magnitude. Probably most cases about 5-20%."

Re: New optimizations for X86 in upcoming GCC 5.0

#33

Post by veselin »

One thing that is not clear to me is if OOP code such as copy constructors will benefit from using the vector registers. Just having vector copy of objects may turn out to be a big difference.

Otherwise examples with array of size 4 elements are nice to show, but in most of these cases it is also easy to use intrinsics.

Re: New optimizations for X86 in upcoming GCC 5.0

#34

Post by GFK_of_xmaspast »

smosher_ wrote: post #29
saurik wrote: post #15

Earlier quoted context omitted.

People contribute to compilers because they need features or performance improvements, not "to kick that other compiler's ass". Sometimes (as here) contributions are from CPU vendors who want to make certain that compilers show off the features of their new hardware. There were tons of great performance impovements in every new version of GCC before clang, and there continue to be today. You just can't model an open…

I disagree, competition itself was good for GCC. Stallman's reaction¹ to LLVM was noisy and possibly childish, but it gave the FSF another important goal: not only should it supply a "libre" compiler but it should also be worth using over the first alternative that comes along. That second goal is a moving target, unlike the first, and it supplies a real motivation to make the best compiler they can. 1. http://www.ph…

GCC hasn't really had a great track record here, things got so bad back in the day that EGCS became necessary (https://gcc.gnu.org/news/announcement.html)

Re: New optimizations for X86 in upcoming GCC 5.0

#35

Post by livemusic »

vardump wrote: post #32
livemusic wrote: post #22

Only loosely related, but I'm curious: What compiler optimizations have the biggest impact on scientific / floating point computation? Integer (audio/image) ops? With modern CPUs performing speculative execution, register renaming, and all the other magic they do, the CPU is acting like an optimizer in its own right. x64 is mostly just a byte code that gets JIT compiled at runtime. I'd be interested in seeing how muc…

This depends entirely on the specific code you're talking about. If the compiler finds out a specific optimization is applicable for a certain block of code, then it uses it. So your question cannot be answered. Only possible answer is "it depends". Another guess: "From nothing to an order of magnitude. Probably most cases about 5-20%."

Yeah, I realize it was an open-ended question. I'm just curious if one was starting a (C-like) compiler from scratch, where the biggest bang for the buck comes from. It seems like peephole optimizations are already handled at runtime by the CPU itself.

Re: New optimizations for X86 in upcoming GCC 5.0

#36

Post by emn13 »

yoklov wrote: post #31
bluecalm wrote: post #28

Earlier quoted context omitted.

I remember that -flto sometimes adds few %'s to overall speed. If you are doing a lot of floating point math you can check various modes. First try is always -Ofast which turns on -ffast-math flag. From the gcc page: -ffast-math Sets -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range. This option causes the preprocessor macro __FAST_MATH__…

`-ffast-math` is a double-edged sword. It can frequently optimize away stuff like NaN checks and the like, breaking code that uses NaN as a missing value. This, specifically, has bitten me before, but there are certainly other areas that it can bite you. OTOH it gives the compiler to do a great deal of algebraic simplifications, including expression reordering. This probably will bring what the compiler can actually…

If -ffast-math won't work, a few more to consider:

-fassociative-math (generally safe unless you're dealing with math written specifically to take advantage of the details of floating point arithmetic)

-fno-signed-zeros - again, though it's possible some code depends on this, it's rather unlikely.

-fno-trapping-math - do you actually use traps?

Re: New optimizations for X86 in upcoming GCC 5.0

#39

Post by username223 »

livemusic wrote: post #22

Only loosely related, but I'm curious: What compiler optimizations have the biggest impact on scientific / floating point computation? Integer (audio/image) ops? With modern CPUs performing speculative execution, register renaming, and all the other magic they do, the CPU is acting like an optimizer in its own right. x64 is mostly just a byte code that gets JIT compiled at runtime. I'd be interested in seeing how muc…

> What compiler optimizations have the biggest impact on scientific / floating point computation?

In my experience, auto-vectorization is the big one. Modern CPUs do 2-, 4-, or 8-wide operations, but it can be hard to convince the compiler to use them. Next is loop tiling, to keep things in cache(s) where possible. These are both hard to do by hand.

Loop interchange to get better locality is nice, but can be done by hand without much trouble by someone who understands computers.

Re: New optimizations for X86 in upcoming GCC 5.0

#40

Post by erichocean »

medgno wrote: post #8

I'm so glad to see auto-vectorization happening more and more often. However, I wonder whether a language that had built-in support for primitive floating-point vector types (e.g., GLSL's vec3, vec4, mat3, mat4) could help the compiler with performing these sorts of optimizations.

Intel's ISPC compiler is an alternative approach that in my experience is easy to code for and produces impressive results. Many CUDA-style algorithms port to it with mostly syntactic changes, and you can interleave CUDA-style code with the usual x86-friendly control flow and data structures.
Post reply on HN