Wouldn't "movzx ecx, al" save one byte of rex.W prefix? Just wondering.
Yes. Also 'xor rcx, rcx' -> 'xor ecx, ecx'.
I got nerd sniped into benchmarking legacy x86 instructions (2019)
11–20 of 47 posts
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#12If you do more than microbenchmarking, then the cache effects start showing up and often the smaller-yet-individually-slower sequence begins to win. But I disagree that the 3 sequences are actually identical in semantics, because the ones containing adds and xors will also affect the flags, while xlat and movs with the arithmetic done in the addressing mode don't. The other thing to note is that pushes and pops are e…
> pushes and pops are essentially free despite containing both a memory access and arithmetic --- I believe they added a special "stack engine" to make this fast starting with the P6
There is a stack engine. But memory accesses and arithmetic are free even without it!
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#13Why 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?
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#14If you do more than microbenchmarking, then the cache effects start showing up and often the smaller-yet-individually-slower sequence begins to win. But I disagree that the 3 sequences are actually identical in semantics, because the ones containing adds and xors will also affect the flags, while xlat and movs with the arithmetic done in the addressing mode don't. The other thing to note is that pushes and pops are e…
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 is safe, unless it's actually overwritten) and there is still a 4 cycle latency, but that probably isn't an issue due to out-of-order execution.
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#15> 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 use an instruction that Intel themselves do not recommend.
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#16If you do more than microbenchmarking, then the cache effects start showing up and often the smaller-yet-individually-slower sequence begins to win. But I disagree that the 3 sequences are actually identical in semantics, because the ones containing adds and xors will also affect the flags, while xlat and movs with the arithmetic done in the addressing mode don't. The other thing to note is that pushes and pops are e…
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
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#17Would 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
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#18Would 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.
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#19>>nerd sniped
I honestly don't know anything about this stuff, but the title is awesome.
Re: I got nerd sniped into benchmarking legacy x86 instructions (2019)
#20Why 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/develop/download/int... (specifically volume 1, section 3.7.5)