Assembly Hall of Shame: a catalog of pathologically slow CPU instructions

What the project catalogs

Not all CPU instructions are fast. Some, for reasons rooted in microarchitecture, take orders of magnitude longer than a typical instruction, and Assembly Hall of Shame is a catalog of them. Its tagline, racing to the bottom of CPU performance, is literal: each entry is a small benchmark isolating one x86 instruction or behavior that is pathologically slow, measuring just how slow it is. The repository's directories read like a rogues' gallery, fxrstor64, wbinvd, rdmsr and wrmsr, split-lock accesses, denormal floating-point, the legacy fsin and fyl2x, cache-line flushes, and more. The audience is systems programmers, security researchers and CPU enthusiasts curious about where and why instructions become expensive, and who enjoy the microarchitectural detail. It is a research and curiosity project by a well-known low-level researcher, so its value is the collected knowledge and the reproducible measurements, not a tool you deploy in an application.

Isolated microbenchmarks per instruction

The mechanism is a set of focused microbenchmarks. Each directory targets one instruction or behavior and contains the code to time it in isolation, so the measurement reflects that instruction's cost rather than being buried in a larger workload. The assembly is deliberately minimal, timing a single instruction such as a vector move or a control-register write, which is how the project pins down the cost of, say, fxrstor64 or a split-lock operation. The categories illustrate the different reasons instructions get slow: microcode-heavy operations, serializing or system-management instructions, cache and memory-ordering effects like wbinvd and mfence, floating-point edge cases like denormals, and legacy transcendental functions. A Makefile builds the benchmarks and there are supporting tools and committed artifacts. The point is precision and reproducibility: by isolating each instruction, the project turns folklore about slow instructions into concrete, measurable numbers on real hardware.

Building and running the benchmarks

Assembly Hall of Shame is a C and assembly project built with make. It uses a Makefile at the top level and per-instruction directories, so you build the benchmarks and run the one you are interested in to time that instruction on your machine. A representative benchmark isolates a single instruction, for example a vector move measured in a timing loop:

vmovdqu 0xfcc003b1, %ymm0

The surrounding harness times such an instruction and reports its cost. Because the measurements are hardware-specific, the meaningful use is to build the benchmarks and run them on your own CPU to see the numbers for your microarchitecture, rather than only reading the committed artifacts. The first real use is building the project and running one benchmark, such as the split-lock or fxrstor64 case, and comparing the timing against a normal instruction, which makes concrete just how large these penalties are on real silicon.

Where a curiosity project is bounded

The limitations follow from its nature. This is a research and curiosity catalog, not a general benchmarking framework or a tool you integrate into an application, so its use is learning and investigation rather than production. Results are inherently hardware-specific: the whole point is microarchitectural behavior, which varies by CPU vendor, model and generation, so a number measured on one machine does not transfer, and reproducing the measurements means running on your own hardware. Some benchmarks touch privileged or system-affecting instructions, wbinvd, control-register writes, model-specific registers, which require appropriate privileges and can perturb the system, so they are for controlled experimentation, not casual runs. And it targets x86 specifically. These are not shortcomings but the boundaries of a focused research project, and they mean Assembly Hall of Shame is for understanding CPU behavior, not for benchmarking software you ship.

The project versus a general benchmark suite

The alternatives are general CPU or microbenchmark suites, or performance-analysis tools like perf. General suites measure broad workloads and give aggregate scores, useful for comparing overall performance but not for isolating why one instruction is slow. Profilers show where time goes in your own program but do not curate the pathological instructions themselves. Assembly Hall of Shame's difference is its focus: it is a curated collection specifically of instructions that are surprisingly expensive, each with an isolating benchmark, so it answers which instructions to avoid in hot paths and by how much, rather than measuring a whole program. Use a general suite to compare machines, a profiler to optimize your own code, and Assembly Hall of Shame to learn which specific instructions carry outsized costs and to measure those costs on your hardware, which is knowledge that then informs how you write or avoid those instructions in performance-critical code.

MIT license and status

Assembly Hall of Shame is MIT-licensed, so it is freely reusable, and it is a C and assembly project with a Makefile, per-instruction directories, tooling and committed artifacts. The last push was on 2026-08-06. It is the kind of focused, expert project whose value is the curation, someone has done the work of finding and isolating the instructions that behave badly, so you do not have to discover them yourself. Adopt it when you want to understand CPU microarchitecture performance or check which instructions carry heavy penalties, build the benchmarks with make and run the ones relevant to your interest on your own hardware since the numbers are machine-specific, and treat the privileged-instruction benchmarks with care. It is a learning and research resource about the low-level cost of x86 instructions, not a suite for benchmarking application software.

Editorial conclusion

Use Assembly Hall of Shame if you want to understand which x86 instructions are pathologically slow and why, and to measure those penalties on your own hardware, as a systems programmer, security researcher or CPU enthusiast. Do not treat it as a general benchmark suite or a production tool, and run its privileged-instruction benchmarks only in a controlled setting. Build it with make, run the benchmarks for the instructions you care about on your own CPU since results are hardware-specific, and use the findings to inform performance-critical code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. xoreaxeaxeax/asm-hall-of-shame on GitHub