Live data from Hacker News

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

acepace.net

31–40 of 47 posts

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

#31
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.

lol, no. Galaxy brain starts somewhere (generally sane and reasonable) and then moves progressively in a certain direction (generally more complicated). In this case the starting point is an instruction sequence that is reminiscent of RISC architectures and then it gets progressively more CISC as you go down the page. The whole point of galaxy brain is that it follows this sequence, and because there’s no special thi…

I've seen galaxy brain comics where the last row is the punchline. The comic might start out moving in a certain direction in a logical way, which may or may not be humorous by itself, but then the last row has a twist, an unexpected interpretation of the direction.

Some bad examples I found on Google:

https://i.redd.it/j0wwzqe2287z.jpg

https://in.pinterest.com/pin/366128644701746892/

The x86 comic may or may not count, depending on whether you expect the reader to know that using those sorts of legacy instructions is not actually an improvement…

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

#32
post #20
post #13

Why didn't the author benchmark the one-instruction equivalent MOV AL,[RBX+AL] that the author uses to explain XLATB? How would its performance differ from the third sequence going through RCX?

x86-64 does not have an addressing mode that uses the 8-bit register alias; in particular, the base and index registers are always either 32-bit (in 32-bit mode) or 64-bit (in 64-bit mode). As such, you need to zero-extend AL to a 64-bit register before using it in an offset addressing mode (or use XLATB). For more information on supported addressing modes, see the manual: https://www.intel.com/content/www/us/en/deve…

One could get rid of the push / pop though, assuming that the high bits of EAX don't need to be saved:

  movzx eax,al     ;could also do "and eax,0ffh"
  mov al,[rbx+rax]

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

#33
post #17

Would someone mind explaining what all the assembly instructions in the meme do? In particular I'm wondering why you would do xor rcx, rcx when that result is always 0

> why you would do xor rcx, rcx when that result is always 0 It's an idiomatic way to populate a register with the value zero. Not sure if it's still true, but IIRC it took fewer cycles than the more obvious "load #0 into $rcx" instruction.

It should be easier for the processor to detect xor-reg-with-itself as a special case. Intel has documented this as the preferred instruction to use since the Pentium afaik.

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

#34
post #31

Earlier quoted context omitted.

lol, no. Galaxy brain starts somewhere (generally sane and reasonable) and then moves progressively in a certain direction (generally more complicated). In this case the starting point is an instruction sequence that is reminiscent of RISC architectures and then it gets progressively more CISC as you go down the page. The whole point of galaxy brain is that it follows this sequence, and because there’s no special thi…

I've seen galaxy brain comics where the last row is the punchline. The comic might start out moving in a certain direction in a logical way, which may or may not be humorous by itself, but then the last row has a twist, an unexpected interpretation of the direction. Some bad examples I found on Google: https://i.redd.it/j0wwzqe2287z.jpg https://in.pinterest.com/pin/366128644701746892/ The x86 comic may or may not cou…

Sure, my point is that the twist doesn't need to be at a particular point, nor does there even need to be a twist. It's just a progression of related images–I think the progression in the ones you're showing is similar to the "evolution of a programmer" joke where a junior engineer starts off with something simple, progressively makes it cleverer and more complicated as they learn more, and eventually return back to the simple solution.

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

#35
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.

I'm not really sure this meme has a punchline. The number of instructions decreases in each panel.

The punchline is that they didn’t think of:

movzx rax, al

mov al, [rax+rbx]

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

#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?

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

#37

>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?

From my understanding, this microcode may and will change between processors, so you lose the possibility of running your code on more than specific CPU type / generation.

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

#38

>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?

> Is there a way Intel can expose microcode and commands to outside so compilers can directly target them instead of X86 instruction set?

Maybe, but MOV is still MOV, so Intel, for the most part, is simply using a subset of x86 (or AMD64) instructions. Except for a few proprietary commands used to implement the more complex commands, most simple instructions are implemented as-is and are passthroughed anyways.

> If yes, would there be anything to gain or lose?

Gains: Very slight faster performance (reduced lookup is always great, but realistically it doesn't matter unless you're doing supercomputer stuff).

Losses: It's pretty much like the kernel land of Linux or NT's undocumented functions: subject to change, fully not supported. Also, cannot be done on the current CPU families anyway since that the microcode can't be updated in such a way that it is worth it.

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

#39
post #35

Earlier quoted context omitted.

I'm not really sure this meme has a punchline. The number of instructions decreases in each panel.

The punchline is that they didn’t think of: movzx rax, al mov al, [rax+rbx]

movzx eax, al

is one byte shorter, but I'm not sure if any of this would make a difference. x86 is tricky.

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

#40

>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?

Isn't microcode specific to a particular microarchitecture, that can, and often does, change between CPU model generations?
Post reply on HN