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

181–190 of 198 posts

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

#181

Post by majewsky »

chkras wrote: post #86
dbcurtis wrote: post #64

Earlier quoted context omitted.

I didn't read Linus's rant on CMOV, but whenever you see a CPU with CMOV, it is because the hardware has very good branch prediction, and the compiler has intimate knowledge of how the branch prediction hardware works. Then the compiler works hard on determining if branches are highly predictable. Is the branch part of closing a loop? Predict that you will stay in the loop. Is the branch checking for an exception con…

Linus rants about most everything, CMOV helped avoid branch prediction issues etc.

At least he has arguments and data to back it up.

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

#183

Post by dejawu »

jcranmer wrote: post #85

In general: * x87 floating point is generally unused (if you have SSE2, which is guaranteed for x86-64) * BCD/ASCII instructions * BTC/BTS/related instructions. These are basically a & (1 * MMX instructions are obsoleted by SSE * There's some legacy cruft (e.g., segment management) that's generally unused by anyone not in 16-bit mode. * There are few odd instructions that are basically no-ops (LFENCE, branch predicto…

So, I don't know a whole lot about the processor design/manufacturing process. If the fabricator (say, Intel) omitted many of these odd legacy and unused instructions, how would it affect the production process?

Would Intel be able to meet the smaller die sizes they're currently having trouble with? Would it make the processors any less expensive to produce at scale (all other things equal)?

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

#184

Post by CyberDildonics »

majewsky wrote: post #175
CyberDildonics wrote: post #114

Earlier quoted context omitted.

The new slides for AMD Zen say explicitly that it has hardware sha256 support.

Careful. Do they mean an ISA extension to support fast SHA-256 implementations in your code, or do they have a SHA-256 implementation in their microcode for CPU-internal use?

I don't know and that goes beyond my point. The original poster said that it is rumored that Intel has a full implementation of sha256 in microcode. I am saying that AMD has confirmed that they at least have it in microcode.

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

#185

Post by dbcurtis »

caf wrote: post #149
dbcurtis wrote: post #64

Earlier quoted context omitted.

I didn't read Linus's rant on CMOV, but whenever you see a CPU with CMOV, it is because the hardware has very good branch prediction, and the compiler has intimate knowledge of how the branch prediction hardware works. Then the compiler works hard on determining if branches are highly predictable. Is the branch part of closing a loop? Predict that you will stay in the loop. Is the branch checking for an exception con…

You don't even need perfect, "insider" branch analysis if you can do profile-guided optimisation using actual branch performance counters in the profile.

Profile guided optimization opt will certainly be better if you profile with a decent data set. And take the time. From what I've experienced, the main users of profile guided optimization are compiler validation engineers.

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

#186

Post by rdtsc »

valleyer wrote: post #161
rdtsc wrote: post #132

Earlier quoted context omitted.

Sorry didn't get the joke, how does it interact with reading the timestamp counter? Isn't LEA intended to calculate addresses? It seems it also doesn't alter flags and can put its result in any register.

The title question, not anything to do with lea. I at least have never seen a compiler emit a rdtsc. (If there is some case where it does [presumably a benchmarking mode?] I'd be interested to hear of it.)

Heh ;-) I see.

Hmm, can't see it being emitted unless used in profiling code. But then as an inline assembly.

Now rdtscp (notice the "p" at the end) is a fencing instruction as well! So I can see someone using that for barriers or when doing serialization.

(Or I guess if a language somehow include getting a fast spinning counter as a feature that could end up as rdtsc* instruction).

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

#187

Post by astrange »

dbcurtis wrote: post #64
shanemhansen wrote: post #24

There are instructions that would almost never be useful. See Linus's rant on cmov http://yarchive.net/comp/linux/cmov.html The tl;dr is that it would only be useful if you are trying to optimize the size of a binary.

I didn't read Linus's rant on CMOV, but whenever you see a CPU with CMOV, it is because the hardware has very good branch prediction, and the compiler has intimate knowledge of how the branch prediction hardware works. Then the compiler works hard on determining if branches are highly predictable. Is the branch part of closing a loop? Predict that you will stay in the loop. Is the branch checking for an exception con…

> I didn't read Linus's rant on CMOV, but whenever you see a CPU with CMOV, it is because the hardware has very good branch prediction, and the compiler has intimate knowledge of how the branch prediction hardware works.

gcc and clang really have no idea how x86 branch predictors work, and they're secret so nobody is going to contribute a model for them. I haven't read the if-conversion pass but it's just some general heuristics.

There also isn't anything guessing if a specific branch is mispredictable or not, it's more like it converts anything that looks "math-like" instead of "control-flow-like" to cmov.

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

#188

Post by vonmoltke »

jcranmer wrote: post #160
fizixer wrote: post #106

Earlier quoted context omitted.

> larger transistor budget ... because we (the chip designer) are okay with larger footprint per core. > specialized instructions are pretty much free ... only after we have fixed the footprint per core. But if we're willing to vary that parameter, then the specialized instructions are not free. Not to mention, the main article of this thread is a strong evidence that those specialized instructions are almost never u…

In terms of die area, even for processors that implement the x86 instruction set, the instruction decode engine is smaller than the out-of-order execution logic (register renaming and the retire queue are quite expensive in space). The branch predictor is larger than both if you have dynamic branch prediction (i.e., if you want a branch predictor that works). Load/store units pretty much dwarf any other execution uni…

Just for reference, IBM tried to do that with the POWER6. Dropped out-of-order execution and (I think) neutered branch prediction, while jacking up the clock frequency. The result was a steaming pile of shit. Performance on our code cratered with respect to the POWER5, Core2, and Nehalem. I ended up having to add ifdef blocks to rewrite some significant algorithms in order to get the POWER6 to be comparable. IBM fixed it somewhat with the POWER6+, but wisely reversed course with the POWER7.

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

#189

Post by cfallin »

olegolegovich wrote: post #159
cfallin wrote: post #28

Earlier quoted context omitted.

> the rep prefixed instructions for string operations ... are actually preferred over a hand-written vectorized loop on Ivy Bridge and up (see [1] section 3.7.7, "Enhanced REP MOVSB and STOSB operation (ERMSB)"). It's indicated by a CPUID feature flag bit (edit: grep for "erms" in /proc/cpuinfo to see this). The reason is that microcode knows more about the dcache microachitecture, load/store units, special features…

Do you have benchmarks, supporting "~break-even vs. 128 bit AVX on Ivy Bridge from 128 bytes up to 2KB" as I have not found it to be the case at least on Haskell (my benchmarking code is @ https://bitbucket.org/olegoandreev/scratch/src/dd7ab9008c59c... ).

I was just quoting the cited PDF ("the section cited above shows..."), which the author(s) did on Ivy Bridge.

I haven't benchmarked it myself. It would be interesting to see how the most common cores today do on this...

Post reply on HN