Assembly Hall of Shame: Racing to the Bottom of CPU Performance

Assembly Hall of Shame: Racing to the Bottom of CPU Performance

This GitHub repository flips instruction latency analysis on its head, hunting for the absolute slowest single instructions on x86 CPUs. Using clever tricks like MMIO reads from PCIe fabric and microcode assists, the project times instructions like `fxrstor64` and `vmovdqu`, with the current champion taking 62 seconds. The leaderboard ranks instructions from `nop` (1 cycle) to the champion (198 billion cycles), showcasing the extremes of CPU performance.

The Assembly Hall of Shame takes the opposite approach: searching for the absolute floor of single-instruction performance.
  1. Retr0id

    Related, and linked in the readme: https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii (using the slow instructions to break SMI)

  2. kazinator

    Bus cycles can be arbitrarily long on any processor that has memory cycles with a hand shake requiring an ack, with no timeout.

    E.g. we can build a board around a MC68000 where we make it lock up forever in a bus cycle, waiting for a DTACK that doesn't arrive.

    Some early microprocessors had clocked bus cycles without handshaking. They would put out an address on some address lines and signal some line together with a read/write indication, and then expect the transfer to be completed within some clock cycles. If nothing is attached to the address, they would read whatever values are on the bus, like maybe all 1's if it is an open drain system that requires the transmitting device to pull to ground to indicate zero.

    I'd say that kind of thing belongs to a hall of shame; it requires software hacks to interface with anything that can't keep up with the prescribed bus cycle.

  3. monocasa

    It says in the rules

    > Trapped/emulated/virtualized instructions may only time the trap, not the handler.

    But I feel like that 12ms write to an ACPI IO port at current leaderboard position 8 is probably trapping to SMM and being handled there.

  4. thyristan

    Depending on his interpretation of the rules about trapped instructions, one could just build a loop in the x86 page tables. Those are usually a tree linked by pointers, and any page table lookup can create another page fault that creates another lookup that...

    Leads to x86 page table MMU magic being turing complete: https://github.com/jbangert/trapcc

    And the simplest thing you can do on such a system is just to loop indefinitely, thus creating a simple instruction with a memory access (mov or anything, doesn't really matter, even the instruction fetch for a nop would work) to take infinite time.

  5. TomatoCo

    This author also has other things like: A compiler that emits only `mov` instructions and another compiler that deliberately messes with the control flow so that, if disassembled, common debuggers will draw symbols like skulls or threats. https://github.com/xoreaxeaxeax/repsych

  6. layer8

    Nop should be #1, because it is infinitely slow for what it does. ;)

  7. markus_zhang

    Does that mean Chris Domas is ready for his next adventure?

  8. codeshaunted

    what im seeing from this chart is that we should be using the nop instruction for everything

More from this day

2026-08-07