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.
someonebaggy 1 hours ago [-]
> Such as whether a callee-saved register really does need to be saved in some particular routine.
Ironically this is your preconceived abstraction of how a compiler has to operate. An ideal compiler could allocate registers differently for each called function: F1()->F2()->F3(), F1 uses r0-5, F2 uses r6-10, F3 uses r11-15, no register saving required in the whole chain. There's no need for a fixed ABI. Such a compiler would look very different from today's ones.
Pannoniae 45 minutes ago [-]
Yeah, that's what MSVC and GCC did on x86, called "custom calling conventions" on MSVC and the regparm attribute on GCC.
All of these were dropped on x64, on x64 (and ARM) you get standard calling conventions for just about everything with proper unwind tables for functions.
It doesn't really "cheat" on the registers unless it inlines a function entirely. LLVM has support for custom calling conventions and pragmas to specify them, this is used by GHC on Haskell and other things, but it's practically unheard of in "normal" C/C++ code.
jcranmer 25 minutes ago [-]
Modifying the ABI of a function requires being able to track down all of the call-sites of the function, which is less trivial than you might assume. ABI concerns also tend to baked in relatively early in the optimization pipeline because you just simply can't get the ABI wrong, and I can think of several instances where the ABI decision causes missed optimizations.
There is also the other issue that a good algorithm for optimizing a problem like register allocation tends to be super-linear (e.g., quadratic), and if you shift the model from "allocate on a per-function basis" to "allocate all functions", the N in the O(N²) goes from "size of function" to "size of program," which is now suddenly a lot more compiler time spent for very modest gains. If register spilling across a function call is a noticeable component of runtime, then you're probably better off inlining that function in the first place!
steveklabnik 9 minutes ago [-]
One of the hardest parts of optimizations is not being penny wise and pound foolish. This sort of thing is a great example of that.
Additionally, a hard part is that all of this can change over time with new hardware! Some patterns that were crucial before everything gained branch predictors are irrelevant now, etc.
44 minutes ago [-]
Eridrus 1 hours ago [-]
What do you think the most impactful savings from hand-written assembly are over optimized Rust today?
Pannoniae 32 minutes ago [-]
1. Better memory locality by knowing what you load and when, exactly.
2. The ability to "cheat" on calling conventions.
3. The ability for techniques like threaded code, and in general, better cache-awareness.
4. Less mov's.
5. Guaranteeing no spilling in important loops.
6. Compilers don't do well with flags registers and you can't read/write them in high level languages. You're hoping your `if (result < a) { carry = 1; }` becomes a direct flag test. Especially important in bignum, you can't really utilise adcx/adox directly from high-level code.
7. Hot/cold layout without PGO. Yes PGO is good but sometimes you know better and PGO isn't very suitable for "configurable" code.
9. Exploiting uninitialised memory for classic party tricks like not initialising a buffer fully (let's say you have a library function with a return buffer. You don't want dynamic allocations for some reason. You can simulate this with a pointer return into a let's say a static 4KB buffer and a count return, you only initialise it until the count. Caller has the responsibility not to overread.)
steveklabnik 30 minutes ago [-]
usually with Rust impactful savings come from writing the Rust differently, not from doing hand-written assembly instead.
This doesn't mean Rust is near perfect, it's just that your first move should be "how do I make the Rust better" and not "I need to drop into asm."
Pannoniae 8 minutes ago [-]
"We’d like to initialise our Vec in parallel, otherwise we’d have to wait for the main thread to fill the entire Vec with a placeholder value only to then have our threads overwrite those placeholder values."
Talk about overengineering :P Multithreaded vector initialisation instead of just...skipping it?
BiscuitBadger 18 minutes ago [-]
Any “Multimedia Extensions” or streaming or whatever beyond what’s available past a 486.
Rust has autovectorization, but a developer knows their algorithms best.
Also AES-NI vs software is no contest.
When people talk about out coding ‘to the metal’ you have to consider what ‘the metal’ provides
compiler-guy 1 hours ago [-]
Entirely situation and application specific. Just like with every other language.
Eridrus 1 hours ago [-]
So there's no patterns at all?
compiler-guy 32 minutes ago [-]
I'm so far downstream from the source language that I know of none specific to Rust. And note someone else's specific answer to your question above that has nothing Rust specific either.
achierius 44 minutes ago [-]
As a compiler engineer, it's not hard to find opportunities for the compiler to produce better code. What's difficult is turning those into generalizable patterns without introducing bugs or regressing performance elsewhere. You're right that as time goes on hand-written assembly won't change, but I see that as increasingly less of an issue now that we have LLMs to pour over and re-analyze what's going on as new releases come out.
moffkalast 1 hours ago [-]
Now I'm wondering if Claude can beat the compiler if I ever need to optimize something a bit more.
j2kun 1 hours ago [-]
> 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?
someonebaggy 2 hours ago [-]
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.
Pannoniae 28 minutes ago [-]
Self-modifying code is a meme unless you're writing an obfuscator... (but even then you can hook the execution so it's a pretty low-tier anti-reversing effort ngl)
For perf reasons it's the equivalent of shooting your leg off to lose weight. You're flushing the instruction cache and breaking prefetch, leading to a huge stall. Then you do it again. And again. It hasn't been in vogue since the 80s...
someonebaggy 5 minutes ago [-]
That depends how far in advance of running the code you're modifying it. You could see a JIT compiler as an extreme type of SMC. Or a Monero miner - its hashing algorithm relies on running randomly generated programs.
SloopJon 1 hours ago [-]
Previous discussion from 2024 (linked in the "Post-publication notes" section):
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.
Ironically this is your preconceived abstraction of how a compiler has to operate. An ideal compiler could allocate registers differently for each called function: F1()->F2()->F3(), F1 uses r0-5, F2 uses r6-10, F3 uses r11-15, no register saving required in the whole chain. There's no need for a fixed ABI. Such a compiler would look very different from today's ones.
All of these were dropped on x64, on x64 (and ARM) you get standard calling conventions for just about everything with proper unwind tables for functions.
It doesn't really "cheat" on the registers unless it inlines a function entirely. LLVM has support for custom calling conventions and pragmas to specify them, this is used by GHC on Haskell and other things, but it's practically unheard of in "normal" C/C++ code.
There is also the other issue that a good algorithm for optimizing a problem like register allocation tends to be super-linear (e.g., quadratic), and if you shift the model from "allocate on a per-function basis" to "allocate all functions", the N in the O(N²) goes from "size of function" to "size of program," which is now suddenly a lot more compiler time spent for very modest gains. If register spilling across a function call is a noticeable component of runtime, then you're probably better off inlining that function in the first place!
Additionally, a hard part is that all of this can change over time with new hardware! Some patterns that were crucial before everything gained branch predictors are irrelevant now, etc.
2. The ability to "cheat" on calling conventions.
3. The ability for techniques like threaded code, and in general, better cache-awareness.
4. Less mov's.
5. Guaranteeing no spilling in important loops.
6. Compilers don't do well with flags registers and you can't read/write them in high level languages. You're hoping your `if (result < a) { carry = 1; }` becomes a direct flag test. Especially important in bignum, you can't really utilise adcx/adox directly from high-level code.
7. Hot/cold layout without PGO. Yes PGO is good but sometimes you know better and PGO isn't very suitable for "configurable" code.
8. Computed goto. See https://github.com/python/cpython/issues/128563 , who doesn't like 10% free performance?
9. Exploiting uninitialised memory for classic party tricks like not initialising a buffer fully (let's say you have a library function with a return buffer. You don't want dynamic allocations for some reason. You can simulate this with a pointer return into a let's say a static 4KB buffer and a count return, you only initialise it until the count. Caller has the responsibility not to overread.)
See stuff like https://davidlattimore.github.io/posts/2025/09/02/rustforge-...
This doesn't mean Rust is near perfect, it's just that your first move should be "how do I make the Rust better" and not "I need to drop into asm."
Talk about overengineering :P Multithreaded vector initialisation instead of just...skipping it?
Rust has autovectorization, but a developer knows their algorithms best.
Also AES-NI vs software is no contest.
When people talk about out coding ‘to the metal’ you have to consider what ‘the metal’ provides
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?
But it takes longer. It's more difficult. That's why the abstraction exists and is still very useful despite its limitations.
For perf reasons it's the equivalent of shooting your leg off to lose weight. You're flushing the instruction cache and breaking prefetch, leading to a huge stall. Then you do it again. And again. It hasn't been in vogue since the 80s...
https://news.ycombinator.com/item?id=40948353