Assembly Hall of Shame

Original Article ↗ Hacker News Discussion ↗

An open-source project cataloging the slowest x86 instructions highlights how certain patterns—like MMIO accesses and subnormal floating-point operations—can stall modern CPUs for milliseconds or even seconds. Commenters connect this to broader concerns about software performance and latency, noting how layers of abstraction, OS input pipelines, and display refresh rates can make today’s machines feel less responsive than much older hardware despite vastly higher throughput. The work is seen as both a playful deep dive into CPU behavior and a practical resource for understanding performance pitfalls and even potential security implications, such as abusing long-running instructions to interfere with system management interrupts.

Project and related tools

  • Repository seen as a fun but serious catalog of pathological x86 instructions and patterns.
  • Tied to a broader body of work: opcode-space bruteforcing for undocumented instructions, “mov-only” compilers, control-flow art in disassembly, binary visualization tools, and SMI-breaking demos.
  • Some ask whether it discovers practical pitfalls vs. being mainly for fun; others point out explicit security/reliability motivations.

Slow instructions, MMIO, and architecture

  • Many worst-case sequences rely on subnormal floating-point operations and MMIO interactions, especially via PCIe and ACPI I/O ports.
  • One standout is fxrstor64 on MMIO, apparently able to stall the PCIe path for tens of seconds; discussion notes lack of forward-progress guarantees.
  • Some feel MMIO-based tricks are “cheating” and prefer results constrained to main memory; uops.info is mentioned for more “pure” instruction timings.

Latency, throughput, and UX

  • Debate over how many instructions fit in 1 ms and why modern systems still feel slow.
  • Classic response-time thresholds (0.1 s “instant”, 1 s flow, 10 s attention) are cited, but others note humans can detect much smaller differences (tens of ms or less, depending on context).
  • Input pipeline details (USB polling, monitor refresh, OS layers) are discussed; older systems sometimes have markedly lower input-to-display latency than modern stacks.
  • Distinction emphasized between throughput optimizations (batching) and latency, with modern designs often favoring the former.

Software bloat and regressions

  • Laws about software bloating to consume hardware gains are invoked.
  • Complaints about modern Notepad/MSPaint changing long-established behaviors and breaking muscle memory; some users avoid newer Windows releases for this reason.

NOP semantics and microarchitectural pedantry

  • Extended back-and-forth on whether nop “does nothing” vs. “increments the instruction pointer,” and how that interacts with decoding and microarchitectural implementation.
  • Discussion touches on legacy encodings (XCHG AX,AX), reserved NOPs, and details of speculative RIP handling.

Timing instructions and measurement quirks

  • rdtsc overhead is discussed; one commenter notes ~25 cycles on certain microarchitectures, while the repo’s reported higher cost likely reflects many in-flight rdtsc calls interfering with each other.
  • rdtsc/rdtscp roles as timing barriers and ordering instructions are briefly contrasted.

Lower-level tricks and edge cases

  • Ideas raised about using TLB misses, scatter/gather, and even page-table / MMU behavior to create arbitrarily long or looping operations.
  • PCIe described as a packet network; extreme latencies via exotic bridges are noted as theoretically possible.