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

How many x86 instructions are there? (2016)

fgiesen.wordpress.com

Post reply on HN
Print view View original

21–30 of 92 posts

Re: How many x86 instructions are there? (2016)

#21

Post by kingsuper20 »

magicalhippo wrote: post #5
FpUser wrote: post #4

I feel sudden urge to write some assembly for fun. Have not done it for at least a couple of years I think.

Then when checking the results are half the speed of what the compiler spits out and the fun is gone. At least that's what happens to me...

I've always been able to beat the compiler, and that's usually after trying to optimize using C. Admittedly, it's a whole lot harder to understand what's fast than it used to be. Access to SSE has it's own benefits.

It's been a problem (optimizing) for some time though. I remember it being some work to beat the compiler on the i960CA. OTOH, I seem to remember the i860 being not-so-great and for sure the TI C80 C compiler was downright awful (per usual for DSPs).

Re: How many x86 instructions are there? (2016)

#23

Post by thechao »

johnklos wrote: post #9

More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one way to look at CISC, I genuinely wonder how much silicon is spent on instructions that are so rarely used they'd be better in software. Or to ask another way: how many instructions are in billions of x86 cores that rarely if ever get used? Hmmm...

It's really more like 6000, if you do the accounting right. And, as someone who just ate a 2x (customer-facing) slow down porting a piece of x86 assembly to ARM, because that "one nifty instruction" was missing, I'm going to say: we should keep all of 'em.

Re: How many x86 instructions are there? (2016)

#24

Post by magicalhippo »

im3w1l wrote: post #13
magicalhippo wrote: post #5

Earlier quoted context omitted.

Then when checking the results are half the speed of what the compiler spits out and the fun is gone. At least that's what happens to me...

Last time I wrote assembly, and it was a long while ago, it was way faster. But let's be honest, 95% of it was doing manual buffering on top of OS api's rather than use C stdlib. And the other 5% were by skipping itoa calls, by doing arithmetic directly on the string representation. I think this is why assembler can be faster many times. Not because I'm better than a compiler. But because the structure of the languag…

Good point, though I usually found that if I then go back and restructure my high-level code, the compiler beat my ASM again.

Re: How many x86 instructions are there? (2016)

#25

Post by Someone »

dreamcompiler wrote: post #16
johnklos wrote: post #9

More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one way to look at CISC, I genuinely wonder how much silicon is spent on instructions that are so rarely used they'd be better in software. Or to ask another way: how many instructions are in billions of x86 cores that rarely if ever get used? Hmmm...

I'd also be curious to discover how many distinct x86 instructions gcc can even emit? I expect the answer is "a lot less than all of them."

If you cheat: all of them. GCC supports in-line assembly.

Of course, that’s not an interesting observation.

It gets (somewhat) interesting when you realize that one may inadvertently include in-line assembly. Do you call including system headers that happen to contain inline assembly cheating? Including headers for a standard C library? Compiling with old-fashioned compiler flags (for example to generate FPU instructions for the x87)?

Re: How many x86 instructions are there? (2016)

#26

Post by magicalhippo »

kingsuper20 wrote: post #21
magicalhippo wrote: post #5

Earlier quoted context omitted.

Then when checking the results are half the speed of what the compiler spits out and the fun is gone. At least that's what happens to me...

I've always been able to beat the compiler, and that's usually after trying to optimize using C. Admittedly, it's a whole lot harder to understand what's fast than it used to be. Access to SSE has it's own benefits. It's been a problem (optimizing) for some time though. I remember it being some work to beat the compiler on the i960CA. OTOH, I seem to remember the i860 being not-so-great and for sure the TI C80 C comp…

Back in the Pentium 1 and earlier days I could beat the compiler. But then it got hard.

And it changes so often, instructions that are fast on one CPU are not so fast on the next one, and vice versa.

Not to mention branch prediction and out-of-order execution makes it very difficult to meaningfully benchmark. Is my code really faster, or just seems like it because some address got better aligned or similar.

I've gotten significant speed gains in certain projects by simply replacing certain hand-optimized assembly in libraries (ie not my code) with the plain C code equivalent. The assembly was probably faster 10-15 years ago, but not anymore...

Re: How many x86 instructions are there? (2016)

#27

Post by thechao »

api wrote: post #18
TwoBit wrote: post #3

ARM has all these variations which make it seem as complicated as x86, but they are distict variations and future CPUs can for example drop 16 bit Thumb fairly clearly.

It's way easier to determine instruction length on ARM. It's usually fixed. That eliminates a lot of brute force thrashing that X86 decoders have to do. It doesn't impact transistor count all that much on a huge modern CPU but it saves a decent amount of power. It's one of the things that factors into why ARM is so power efficient. ARM has also been willing to drop older optional legacy stuff like Java oriented instr…

It's not that variable length is expensive, it's that variable length the way Intel does it is expensive. For instance — not that this is a good idea — you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. Then you can have your variable-width-cake-and-eat-your-fast-decode-too.

Re: How many x86 instructions are there? (2016)

#29

Post by mhh__ »

thechao wrote: post #23
johnklos wrote: post #9

More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one way to look at CISC, I genuinely wonder how much silicon is spent on instructions that are so rarely used they'd be better in software. Or to ask another way: how many instructions are in billions of x86 cores that rarely if ever get used? Hmmm...

It's really more like 6000, if you do the accounting right. And, as someone who just ate a 2x (customer-facing) slow down porting a piece of x86 assembly to ARM, because that "one nifty instruction" was missing, I'm going to say: we should keep all of 'em.

Which one?

Re: How many x86 instructions are there? (2016)

#30

Post by mhh__ »

magicalhippo wrote: post #26
kingsuper20 wrote: post #21

Earlier quoted context omitted.

I've always been able to beat the compiler, and that's usually after trying to optimize using C. Admittedly, it's a whole lot harder to understand what's fast than it used to be. Access to SSE has it's own benefits. It's been a problem (optimizing) for some time though. I remember it being some work to beat the compiler on the i960CA. OTOH, I seem to remember the i860 being not-so-great and for sure the TI C80 C comp…

Back in the Pentium 1 and earlier days I could beat the compiler. But then it got hard. And it changes so often, instructions that are fast on one CPU are not so fast on the next one, and vice versa. Not to mention branch prediction and out-of-order execution makes it very difficult to meaningfully benchmark. Is my code really faster, or just seems like it because some address got better aligned or similar. I've gott…

I've started injecting code fragments into spectre exploits as a way of seeing whether the CPU likes them or not.
Post reply on HN