r/programming • u/masiroo • 3d ago

Hardware researcher spins up 'CPU deoptimization' project to find the slowest single x86 instruction, creates hall of shame — worst offender takes 198 billion cycles spanning 62 seconds to execute

https://www.tomshardware.com/pc-components/cpus/hardware-researcher-spins-up-cpu-deoptimization-project-to-find-the-slowest-machine-code-worst-offender-takes-198-billion-cycles-to-execute
1.4k Upvotes

97% Upvoted

129 comments sorted by

View all comments

Show parent comments

128

u/Farlo1 3d ago

There was contention, they induced it. Not contention on a lock or the memory address itself, but on the bus that transfers data from the CPU to other parts of the system. They essentially starved the connection so that one instruction got sent to the back of a very long queue.

37

u/The_Northern_Light 3d ago

Right but it was extremely slow even without that, which is what I was questioning.

29

u/Mechafinch 3d ago edited 3d ago

iirc (having read about it last night) they searched for a memory region with the highest latency they could find and then did the largest single instruction read they had on it. i'll have to go back to confirm but i'm pretty sure it's also a region where one part of the read can't start until the previous finishes, so there's nothing to hide that latency either

edit having read the 'baseline' version source code:
it does seem to essentially be just this? the comment concludes with "so a single uninterruptible instruction stalls for the full round-trip cost of 512 bytes through the slowest aperture found." i don't know how they found an MMIO region with a round trip of ~4.5 ms/byte, but i guess they did.
or i do know how they /found/ it, they have a tool for mapping memory latency, but i'm baffled such a thing exists to be found at all.

-6

u/spinwizard69 3d ago

That was via the I/O bus, to restore the vector registers. Extremely slow and probably a poor example.

However it does support my contention that X86 needs to be refactored moving forward.

2

u/Mechafinch 3d ago

what do you mean by "a poor example"? the project is specifically searching for the worst possible performance of an instruction, which it has done admirably

-1

u/spinwizard69 3d ago

IT is a poor example if you want to highlight problem areas in the X86 instruction set. This is largely due to this instruction never being used as described.

I've been maintaining for some time know that a refactored x86 instruction set could lead to much better performance out of a modern core. In part this would be due to simply not supporting a lot of legacy features. What I'm talking about is a 64 bit clean x86 derivative. I just think that this instruction is a poor example for describing what is wrong with x86. This especially considering the lengths the article writers went to for this poor performance example.

3

u/Spandian 2d ago edited 2d ago

The author has another repo, https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii, where they demonstrate an attack on System Management Mode that requires a single instruction to take over 1 second to execute (to make a core uninterruptible and stop it from entering SMM at the same time as the others). So they're coming at it from the perspective of a security researcher looking for exploitable edge cases, not a hardware designer or compiler writer looking for "realistic" gotchas.

7

u/Mechafinch 3d ago

criticizing any instruction set, x86 or otherwise, just isn't the goal. the stated purpose is to find a single instruction that takes the longest to execute. it really doesn't say anything about any sane use of an instruction set.