Assembly Hall of Shame

Related, and linked in the readme: https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii (using the slow instructions to break SMI) reply: I wish they would just explain it in normal terms instead of this nasty LLM "engaging blog post" style

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.

Nop should be #1, because it is infinitely slow for what it does. ;) reply: Strategy: nop does nothing. It opens the leaderboard accordingly.Score: 1 cycles Time: 0 nanoseconds

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 reply: He also bruteforced the entire opcode space to find undocumented instructions (sandsifter).

It’s crazy how computers still seem to get perceivably slow every few years, given how many instructions can be executed in 1ms. Shameful, even..What’s that law called about programmers wasting all the compute on abstraction? reply: There are two aspects to compute performance: latency and throughput.There has been a ton of work to improve throughput, but that's often come at the cost of latency, because a great technique to improve throughput is batching, to avoid the per-task overhead cost.We've also added many layers of abstraction.A seminal example is Dan Luu's "computer latency" table (2017) https://danluu.com/input-lag/, which measures the time between a keypress and visible changes on the screen, and wherein an Apple IIe has latency 5x lower than a Lenovo X1 Carbon on Windows.From some perspective, you could say that the Lenovo on Windows example is an impressive feat of engineering, considering all the subsystems involved (USB, interrupt dispatcher, input layer, windowing system, double-buffering...)This throughput-over-latency tradeoff can be seen across the entire computer landscape design.

Related, somehow: Core War [0].[0]: https://en.wikipedia.org/wiki/Core_War

what im seeing from this chart is that we should be using the nop instruction for everything reply: Well the best code is no code. Nop could be second best though.

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

Very cool! Also, huh interesting. I’ve used rdtsc to measure cycle diffs but had no idea its execution takes that long. Is that common across architectures?

just curious, how much do these actually discover useful practices or pitfalls, on top of just being for fun?

A great resource for any performance deoptimization.

Oh wow, glad to see Chris Domas active online again!

Using MMIO is cheating and makes the results very boring.It would be much more interesting to know the results if you're only allowed to use main memory.

It'd be really interesting to see whether the winning (losing?) instructions/strategies would be different on other architectures. At least right now the top spot (`fxrstor64` on MMIO, starve PCIe) seems relatively architecture-independent, but maybe something about MMIO ordering rules on e.g. POWER would be different enough to change that -- or perhaps open up new avenues?I wonder what the actual limit on this `fxrstor64` is right now. If you can stall the PCIe bus for that long, then why not indefinitely? Certainly there's no forward progress guarantee here.

There’s definitely strategies here; A lot of the floating point operations use subnormals, and a lot of the worst instructions are slowed down by really, really fucking with MMIO.