The slowest x86 instruction on Christopher Domas’ new public leaderboard took 62 seconds to finish, at least under a setup designed to make a processor’s I/O path miserable. The entry records 198,002,498,236 normalized cycles for fxrstor64 on an AMD Ryzen 7 5800H. It is a constructed worst case, not a claim about ordinary Ryzen performance or the usual latency of that instruction.
Domas’ repository, called the Assembly Hall of Shame, reverses the purpose of conventional instruction-latency work. Rather than using latency measurements to optimize a processor design or an application, it seeks the lowest possible performance for one scored machine instruction. The repository’s first commit is dated August 6, 2026.
Why did the slowest x86 instruction take 62 seconds?
The record depends on the surroundings supplied to fxrstor64, not the opcode in isolation. Domas configured the instruction to load 512 bytes of FPU, MMX and XMM state from a high-latency memory-mapped I/O region in the PCIe fabric. Other CPU cores then repeatedly issued 4-byte reads to another high-latency MMIO location while that load was underway.
According to the project’s description, those reads saturated the PCIe root complex and endpoint with non-posted transactions. The timed state restore had to wait behind that traffic. Before adding the contention step, Tom’s Hardware reported that the MMIO state load had taken more than 74 billion cycles, or a little over 23 seconds.
That distinction is the whole point of the number. The leaderboard permits whatever preparation a test needs, while scoring only one instruction. In this case, multicore contention and deliberately hostile I/O conditions are part of the preparation. A normal program restoring processor state is not thereby expected to pause for a minute.
What qualifies for the Assembly Hall of Shame?
The project’s rules exclude interruptible instructions, including rep movs and pause. A trapped, emulated or virtualized instruction may count the trap itself, but not time spent in its handler. Scores are normalized to each CPU’s base-clock frequency, and the machines must retain factory-stock hardware configurations.
The rules make this a peculiar but bounded exercise: the leaderboard measures one instruction’s completion under an adverse setup, not a general benchmark of a chip or an instruction set. For context, its low-latency end includes a one-cycle nop, a 49-cycle rdtsc, a 77-cycle configured idivq test and a 112-cycle enter test. Those entries ran on an Intel Core i7-8559U, so they are useful scale rather than direct comparisons with the Ryzen record.
The project currently publishes an x86 table. Tom’s Hardware reported that Domas planned Arm and RISC-V leaderboards, and that a possible Intel Sapphire Rapids experiment using xrstore64 and an 8KB state area could exceed 1 trillion cycles. Neither is a recorded result. For the broader distinction among instruction-set families, see Arm vs. x86.
This story draws on original reporting from Tom's Hardware.
