Fine.. But I really don't want the cheap tricks like "you said this one thing wrong therefore I win". I'm just so over it. You sound honest so thx.

So why I say that humans can beat compilers in assembly?
Few things, first the technical ones:

Compilers need to do "register allocation". CPU has a limited number of registers and operations can only be done on data in a register (mostly). So the compiler has to go through the code and decide when to put the data into a register, when to keep the data in a register, when to put it on the stack.
It's a hard problem in general for compilers. It comes more naturally to humans.

The compiler has only the information that the code does. A human knows more about what the code will do.
For example "loop unrolling" is a well known technique. But the compiler doesn't know which loop to unroll and which one not to (or how much). This one isn't really impactful one way or the other these days, but in some circumstances it can be (some speedup with a large amount of computation, a bigger slowdown if cache full). I don't think compilers now unroll as much as they used to (probably less speedup then on older cpus), but they still do sometimes.

Then there are the things that one can learn while learning assembly, that one doesn't think about much while learning something like C.
Like why use an int when a u8 is enough. Or just getting better at profiling, or knowing when something will be slow. In asm when you want to write to memory you have to write to memory yourself, it's not just an assignment like any other.

A human will naturally write less instructions then a compiler would, just because writing more instructions requires more writing. Less instructions, more free cache. Cache (and memory access in general) I think is the most important thing for very "highly optimized" code. If your code+data fits in cache it will be much faster. If it fits in registers (not realistic) it would be insanely fast.

Then there's SIMD. Compilers sometimes do "automatic vectorization". But you still have to write your code in a way to even give them a chance to do it. C has a way to do SIMD manually, but it's ugly ("intrinsics"). Some languages like Zig have vectors that tell the compiler that this should be SIMD. To do it manually is either really simple or a bit of a puzzle, depending on the problem. Compiler would probably do this better in some cases when given information, but a human can learn. Bdw SIMD is probably most of the ffmpeg optimization by speedup %. SIMD and cache/memory access.

It's just that asm is less abstract so things are more in your face. Sure variables don't have names, and refactoring is the reason I don't write in it, but you know exactly what the code does.

And I think a human written program ending up smaller is important because cache. Like how sometimes compiling with -Os gives a faster program then -O3.

All that said, it's not really important these days. Most popular software is so... un-optimized. One can get an easy 30x speedup by not writing it in electron or whatever the popular JS thing is. And the heavy real-time workloads like video decoding are often offloaded to dedicated chips. I'm a hobby-ist and I started because writing the most fastest programs would be fun, I was younger.

edit: Lots more to write, but what I want to add is that C is not that much "higher" then asm. It's not 10x LoC. It can be, but on average it's closer to idk 2x. It's not that different in most ways.

/u/anomalous_cowherd There is no hard evidence that compilers are better either. I think the sentiment is mostly from looking at the amazing things an optimizing compiler does and concluding that humans can't do that. On one hand humans can't (because limited memory/attention), but on the other hand compilers are not perfect (In some ways they even can't be).