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

Does a compiler use all x86 instructions? (2010)

pepijndevos.nl

Post reply on HN
Print view View original

191–198 of 198 posts

Re: Does a compiler use all x86 instructions? (2010)

#191

Post by epsylon »

gpderetta wrote: post #77
PeCaN wrote: post #76

Earlier quoted context omitted.

Nearly all x86_64 instructions are microcoded on modern Intel and AMD CPUs. That does not mean they're slow. Some instructions may end up slow when the microcode isn't updated to take advantage of the latest processor iteration (I recall this happened to rep movs at some point, which gave it its bad reputation, even though it was fixed). That probably happens often for legacy instructions.

No, the large majority of instructions are not microcoded. In addition to microcode having a performance penality by itself, a modern intel cpu machine can decode only one microcoded instruction per cycle, while it normally can decode up to 4 non-microcoded instructions per cycle. Note that microcoding and uop splitting are different things.

Do you have any reference for most of the stuff you are talking about in the comments here? I'd like to understand it better. Thanks.

Re: Does a compiler use all x86 instructions? (2010)

#192

Post by gpderetta »

epsylon wrote: post #191
gpderetta wrote: post #77

Earlier quoted context omitted.

No, the large majority of instructions are not microcoded. In addition to microcode having a performance penality by itself, a modern intel cpu machine can decode only one microcoded instruction per cycle, while it normally can decode up to 4 non-microcoded instructions per cycle. Note that microcoding and uop splitting are different things.

Do you have any reference for most of the stuff you are talking about in the comments here? I'd like to understand it better. Thanks.

The bible are Agner Fog optimization manuals [1] which contain quite a detailed description of the microarchitecture of intel and AMD CPUs from the pentium era till today. They are based on the extensive reverse engineering done by the author.

David Kanter microarchitecture articles at RWT [2] are also quite good.

Intel manuals are quite detailed as well.

[1] http://www.agner.org/optimize/

[2] http://www.realworldtech.com/cpu/

Re: Does a compiler use all x86 instructions? (2010)

#194

Post by pkaye »

epsylon wrote: post #191
gpderetta wrote: post #77

Earlier quoted context omitted.

No, the large majority of instructions are not microcoded. In addition to microcode having a performance penality by itself, a modern intel cpu machine can decode only one microcoded instruction per cycle, while it normally can decode up to 4 non-microcoded instructions per cycle. Note that microcoding and uop splitting are different things.

Do you have any reference for most of the stuff you are talking about in the comments here? I'd like to understand it better. Thanks.

Micro-ops are smaller units of work to execute a CPU instruction. Some instruction may take 1 uop like adding two registers together. Some may take multiple uops like adding a register and a memory location. For example split into one uop to read from memory into a temporary register and then another uop to add that temporary register with another.

There are instruction decoders that quickly breaks up an CPU instruction into a series of uops. It needs to be fast or the execution units may become idle. So there are limitations like breaking up into 4 uops max. On the Intel x86 processors, there were lots of quite complex instructions that might need to be broken down into more than 4 uops so a separate microcode modules can handle those. However there is only one of those so it can become a performance bottleneck if you use too many of those complex instructions.

If you really want a technical book on this, read "Modern Processor Design" by Shen. A bit pricey though (I got one second hand cheap.)

Re: Does a compiler use all x86 instructions? (2010)

#195

Post by krylon »

SixSigma wrote: post #111
krylon wrote: post #104

Earlier quoted context omitted.

Why would Microsoft want to stop people running their system on newer CPUs?

Hmm, I got that slightly backwards, Win10 will not work on older CPUs > Going forward, as new silicon generations are introduced, they will require the latest Windows platform at that time for support. This enables us to focus on deep integration between Windows and the silicon, while maintaining maximum reliability and compatibility with previous generations of platform and silicon. For example, Windows 10 will be t…

> Hmm, I got that slightly backwards, Win10 will not work on older CPUs

That makes more sense.

I remember that years ago, there was this tongue-in-cheek conspiracy theory floating around that Microsoft and Intel had some kind of deal that new versions of Windows would pretty much require one to get a new computer so it would run decently, in order to boost Intel's sales. Maybe there was something to it? ;-)

OTOH: "For example, Windows 10 will be the only supported Windows platform on Intel’s upcoming “Kaby Lake” silicon" - that does indeed sound like one could run into trouble trying to run older versions of Windows on new chips... I wonder if there are hard technical reasons for this. After all, both Intel and Microsoft had put a lot of hard work into preserving backwards compatibility.

Re: Does a compiler use all x86 instructions? (2010)

#196

Post by mike_hearn »

gpderetta wrote: post #179
mike_hearn wrote: post #169

Earlier quoted context omitted.

I would disagree with almost everything you said here. JIT compilers can beat equivalent AOT compilers by about 20%, or at least, that's the kind of loss you get in HotSpot from not doing profile guided compilation and doing it all AOT instead. So that point seems wrong. If you're comparing Java and C++ well, that is affected by many things and you can quite easily construct microbenchmarks where Java beats C++. In r…

> I would disagree with almost everything you said here. reality seems to agree with the parent. Case in point there are no production level JIT compilers for C/C++. The fact that a java AOT compiler is not competitive with HotSpot might have more to do to the maturity of HotSpot and the amenability of Java to AOT compilation. > JIT compilers tend to be better at unguided vectorisation than AOT compilers because they…

There is a JIT compiler for C/C++, it's called Sulong. However, it's a research project indeed.

The 20% comparison is HotSpot in AOT mode (it's being developed) vs HotSpot in JITC mode. So I think it's one of the best figures you're going to get. Speculative, profile guided optimisations aren't going to double your speed or anything like that, but a 20% win is big enough to matter: it's like getting a free additional core on contemporary machines.

Yes you can do runtime dispatching to different functions, but how many apps actually do so? I've seen a lot of software that doesn't bother, or only has a "plain vanilla" and a "low-rev SSE" version.

HotSpot has got steadily better at auto-vectorisation with time. The unreleased Java 9 version has had a lot of patches from Intel go in that make it better at using the latest vector units more frequently.

Re: Does a compiler use all x86 instructions? (2010)

#197

Post by noselasd »

column wrote: post #190
noselasd wrote: post #171

Earlier quoted context omitted.

It might be used to avoid a conditional.

Thank you for your answer but frankly I don't understand it. Could you please elaborate?

Generally multiplying with 1 can be used to just do (the equivalent in assembly of):

    a  = a * b;
instead of

    if (b != 1)
       a  = a * b;
Which is normally a win, as branching are expensive vs multiplication.

Re: Does a compiler use all x86 instructions? (2010)

#198

Post by gpderetta »

mike_hearn wrote: post #196
gpderetta wrote: post #179

Earlier quoted context omitted.

> I would disagree with almost everything you said here. reality seems to agree with the parent. Case in point there are no production level JIT compilers for C/C++. The fact that a java AOT compiler is not competitive with HotSpot might have more to do to the maturity of HotSpot and the amenability of Java to AOT compilation. > JIT compilers tend to be better at unguided vectorisation than AOT compilers because they…

There is a JIT compiler for C/C++, it's called Sulong. However, it's a research project indeed. The 20% comparison is HotSpot in AOT mode (it's being developed) vs HotSpot in JITC mode. So I think it's one of the best figures you're going to get. Speculative, profile guided optimisations aren't going to double your speed or anything like that, but a 20% win is big enough to matter: it's like getting a free additional…

> yes you can do runtime dispatching to different functions, but how many apps actually do so? I've seen a lot of software that doesn't bother, or only has a "plain vanilla" and a "low-rev SSE" version.

those that do care I guess? Games, video encoders/decoders. Most custom HPC applications are simply compiled for whatever architecture is running on the cluster and don't bother with anything else.

Post reply on HN