Beating the Compiler

There are literally thousands of compiler engineers who pore over the assembly a compiler generates, and then finds ways to make it better. I get paid to figure out where the compiler can do better, and often a step in that is to hand-code my own replacement. I then teach the compiler to do that.

But even beyond that, the compiler can't make certain assumptions that an assembly writer can. Such as whether a callee-saved register really does need to be saved in some particular routine. Or even pushing an extra parameter in unusual cases.

So it is entirely possible to beat the compiler, it's doable under certain circumstances, even today.

But you also have the danger of your loving hand-crafted assembly beating the compiler today. But next year the compiler is even smarter, the hardware may have changed in subtle ways, and the compiler will know and improve the code it generates.

Your hand-written code won't change unless you revisit it.

> In modern times, everyone knows that writing assembly is a fool's errand

ffmpeg is like 10% assembly. I think something similar is true of all video encoders. OpenSSL and libsodium write some of their core math routines in assembly (e.g,. NTT).

So maybe this myth should die?

Previous discussion from 2024 (linked in the "Post-publication notes" section):

https://news.ycombinator.com/item?id=40948353

Compilers are pretty good. Really good, even. But languages, even C, are abstractions, which necessarily constrain the level below. This threaded-code jump thing is just not possible to express in C. Even the best abstraction can often be beaten by something the abstraction can't express. Self-modifying code is one example. So is this threaded interpreter with its non-structured control flow.

But it takes longer. It's more difficult. That's why the abstraction exists and is still very useful despite its limitations.