HN Debrief

Assembly Hall of Shame

  • Programming
  • Hardware
  • Performance
  • Security
  • Developer Tools

The repo is a leaderboard of “slow code” on x86. It catalogs tiny assembly snippets that maximize cycles per instruction, along with short explanations of why they stall so badly. Some entries are classic microarchitecture pain points like subnormal floating point values. Others lean on memory-mapped I/O, PCIe starvation, or weird corners of the platform. The result is half educational reference and half stunt project.

If you care about low-latency software, the repo is a vivid reminder that hardware side effects, firmware traps, and I/O ordering can dwarf normal instruction costs. Treat benchmark results that touch MMIO, ACPI, or timing instructions with suspicion, because they may be measuring platform plumbing rather than the core you think you are testing.

Discussion mood

Amused and impressed, with a strong undercurrent of pedantry. People liked the repo as a clever performance oddity, but the most engaged comments challenged whether the top results were fair instruction benchmarks once MMIO, ACPI, PCIe, and firmware traps entered the picture.

Key insights

  1. 01

    MMIO turns it into a platform benchmark

    Letting memory-mapped I/O dominate the leaderboard changes the problem from “what instruction is slow” to “what hardware path can I abuse hardest.” That is why entries involving ACPI ports, PCIe starvation, and device-facing `fxrstor64` feel less like processor archaeology and more like measuring bus ordering, firmware handlers, or peripherals that happen to sit behind an instruction.

    If you reuse ideas from this repo for benchmarking or testing, split core-only instruction costs from platform side effects. A separate category for MMIO and firmware-triggering tricks would make results far more actionable.

      Attribution:
    • monocasa #1
    • IshKebab #1
    • achierius #1
    • arn3n #1
  2. 02

    Latency wins over raw instruction speed

    The funniest part of a “slow instruction” contest is how little it explains about why computers feel slow. User experience is usually gated by end-to-end latency through input devices, operating system layers, compositors, and displays. The comments tied that to Dan Luu’s input lag measurements and to longstanding usability thresholds around 100 milliseconds. The point is not that CPUs are slow. It is that modern systems burn their budget everywhere else.

    When a product feels sluggish, start by tracing the full interaction path before tuning tight loops. You can save dozens of cycles and still lose badly to buffering, batching, refresh cadence, or extra OS layers.

      Attribution:
    • AceJohnny2 #1
    • m463 #1
    • citelao #1
  3. 03

    This fits a long line of opcode abuse

    The repo makes more sense when you place it next to the same author’s older work. People immediately connected it to sandsifter, which brute-forced x86 opcode space for undocumented behavior, and to repos like `repsych` and `smiiiiiiiiiiiiiiii`. That history changes the read from “novelty leaderboard” to “another artifact from someone who probes the weird edges of x86 for a living.”

    If this repo is useful to you, the adjacent projects are worth reading too. They cover undocumented instructions, debugger-hostile binaries, and firmware timing abuse that can inform security research and low-level testing.

      Attribution:
    • TomatoCo #1
    • inigyou #1
    • markus_zhang #1
    • spoocecow #1
  4. 04

    Timing the timer is tricky

    Even `RDTSC` sparked correction. One commenter said the ~49-cycle figure shown in the repo looks high for Skylake-era chips, where `RDTSC` is closer to ~25 cycles. Another pointed out that serialization behavior is easy to mix up with `RDTSCP`. That matters because once your measuring tool has its own latency and ordering quirks, small benchmark claims get shaky fast.

    If you benchmark at cycle granularity, document the exact timing instruction and serialization method you used. Otherwise readers cannot tell whether they are seeing code cost, timer cost, or pipeline ordering artifacts.

      Attribution:
    • michalsustr #1
    • pbsd #1
    • inigyou #1
    • rrampage #1

Against the grain

  1. 01

    The writeup style gets in the way

    The repo’s playful presentation put at least one technically interested reader off. The complaint was not about the content. It was that the “engaging blog post” tone made low-level explanations harder to parse than a plain statement of what each trick is doing and why it is slow.

    If you publish niche technical work, keep the style from obscuring the mechanism. A crisp plain-language explanation broadens the audience more than extra personality does.

      Attribution:
    • jonathrg #1
  2. 02

    Even NOP is not a settled joke

    The joke that `NOP` is infinitely slow for doing nothing turned into a real architecture argument. Replies split over whether modern x86 simply discards it in decode, whether it still counts as incrementing the instruction pointer, and whether the old 8086 encoding as `XCHG AX,AX` once ran actual microcode. That is a useful reminder that even “do nothing” instructions carry historical baggage and implementation differences.

    Do not assume familiar instructions mean the same thing across generations. If you are reasoning from old ISA lore, check what current decoders and microarchitectures actually do.

      Attribution:
    • layer8 #1
    • jooops1 #1
    • fluoridation #1
    • EvanAnderson #1
    • JoeAltmaier #1

In plain english

ACPI ↩
Advanced Configuration and Power Interface, a standard used by firmware and operating systems for power management and hardware configuration.
fxrstor64 ↩
An x86 instruction that restores floating-point and SIMD processor state from memory in 64-bit mode.
MMIO ↩
Memory-mapped input/output, a way hardware devices are controlled by reading and writing to special memory addresses instead of separate I/O instructions.
NOP ↩
No operation, an instruction that intentionally has no visible effect other than advancing execution.
PCIe ↩
Peripheral Component Interconnect Express, the high-speed bus used to connect devices like graphics cards and storage controllers to a computer.
RDTSC ↩
Read Time-Stamp Counter, an x86 instruction that reads a CPU cycle counter for fine-grained timing.
RDTSCP ↩
A variant of Read Time-Stamp Counter that also returns processor information and provides stronger ordering guarantees for timing.
subnormal ↩
A very small floating-point number represented in a special format that often executes much more slowly than normal values.
x86 ↩
A widely used family of processor instruction set architectures that powers most desktop and server CPUs from Intel and AMD.

Reference links

Related projects by the same author

  • smiiiiiiiiiiiiiiii
    Linked as another project that abuses slow instructions to trigger or stretch firmware behavior through System Management Interrupts.
  • repsych
    Mentioned as a compiler and binary-obfuscation project that manipulates control flow and debugger output.

Performance and latency references

Background and technical references