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

I got nerd sniped into benchmarking legacy x86 instructions (2019)

acepace.net

Post reply on HN
Print view View original

41–47 of 47 posts

Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)

#41

Post by anamax »

DeathArrow wrote: post #36

>However, since that time, all modern CPUs have turned RISC-like, by internally using a reduced instruction set and translating the ISA opcodes into internal commands, some implemented using CPU microcode. Is there a way Intel can expose microcode and commands to outside so compilers can directly target them instead of X86 instruction set? If yes, would there be anything to gain or lose?

Micro-ops often have more bits than the ISA they're implementing, so you'd pay a program-size penalty.

Moreover, Intel (and I assume AMD), will take a sequence of micro ops corresponding to a sequence of "instructions" and optimize the micro-op sequence based on dynamic usage, together with "undo" for when the usage assumptions are wrong.

Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)

#42

Post by wongarsu »

DeathArrow wrote: post #36

>However, since that time, all modern CPUs have turned RISC-like, by internally using a reduced instruction set and translating the ISA opcodes into internal commands, some implemented using CPU microcode. Is there a way Intel can expose microcode and commands to outside so compilers can directly target them instead of X86 instruction set? If yes, would there be anything to gain or lose?

One advantage of not exposing microcode is that newer processors can add support for new microcode instructions and map existing X86 instructions to them. In a sense there's a tiny JIT in the CPU that turns X86 into processor-optimized code.

The disadvantage is of course that this is complex to do in silicon, and the CPU might lack some insights that the compiler had. As I understand it Itanium was HP's and Intel's attempt to give a lot more power to the compiler, with an instruction set that better matches what's going on under the hood. But we all know how that ended: performance was lackluster and the Itanic was nothing but a waste of money for everyone involved.

GPUs have successfully moved the microcode translation one layer up, you generally compile to an intermediate ISA (let's call it a bytecode) and when you load the program (or shader) the GPU driver translates it to GPU-specific instructions. But that model doesn't easily translate to CPUs.

Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)

#44

Post by dspillett »

b5n wrote: post #3

> The meme is wrong The third panel is generally meant to be the correct technical answer, while the last panel is reserved for the punchline. Understanding the 'galaxy brain' format might have saved the author the trouble (or at least guided proper expectations), although it was a cool exercise.

> while the last panel is reserved for the punchline

The meme gets used in a number of similar but different ways. Sometimes the last panel is the sequence taken to a logical but unrealistic extreme.

Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)

#45

Post by dataangel »

brigade wrote: post #16
phire wrote: post #14

Earlier quoted context omitted.

The stack engine only handles the adjustment of the stack pointer, converting the push and pop to regular load/store uops. But the store-then-load pattern is optimised by the store buffers, which do store-forwarding to forward the result of the in-flight store to the load without having to go though L1 cache. It's not quite free, you still have to complete the store (the cpu can't assume optimising away a stack push…

It gets more "free" once you have the zero-latency loads introduced in Zen 2 and the load can be speculatively replaced with a register move if the store is close and obvious enough

How can you have a zero latency load?

Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)

#46

Post by [deleted] »

dataangel wrote: post #45
brigade wrote: post #16

Earlier quoted context omitted.

It gets more "free" once you have the zero-latency loads introduced in Zen 2 and the load can be speculatively replaced with a register move if the store is close and obvious enough

How can you have a zero latency load?

[deleted]

Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)

#47

Post by brigade »

dataangel wrote: post #45
brigade wrote: post #16

Earlier quoted context omitted.

It gets more "free" once you have the zero-latency loads introduced in Zen 2 and the load can be speculatively replaced with a register move if the store is close and obvious enough

How can you have a zero latency load?

Similar way register movs can have zero latency - the output is renamed from the register source of the corresponding store. Which takes the load out of the dependency chain, effectively having zero latency so long as the correct store was identified.
Post reply on HN