Sure, there are some applications in which we may need to squeeze every ounce of efficiency out of our programs, but in this day and age you’ll be hard pressed to come any where close to the code optimizations made by modern compilers. Does anyone who regularly writes assembly really believe that it's difficult to write better code than a modern compiler? This isn't my experience at all. Instead, I'd say that with ju…
> It's almost as if there is some compiler-writers-protection-racket out there that threatens anyone who doesn't bow to the powers of the modern compiler.
A lot of it seems to come from the "religious belief in abstraction" that is prevalent among academics; the belief that somehow, a "higher level" solution is always better.
> The wonder isn't that they generate perfect code (by and large, they don't), but that they can optimize as well as they do without introducing bugs left and right.
It's not so surprising when you consider that compilers are just following patterns/transformations when they generate or optimise code, and these patterns are designed to be very general so they work for all cases, even when they're not the most efficient way to do it in some of these cases. When a human is writing the Asm there is (or should be - otherwise you'd be better off just using a compiler) a higher level of thought, a different process, one that may be more prone to errors but one that also shows some form of creativity - thinking about the specific application and, understanding that, applying a transformation/pattern that is only applicable in that case to improve the generated code.
Size optimisation is also another area where even a novice Asm programmer can very easily beat a compiler due to this general/specific pattern-ness divide. From what I've seen, compilers start with often overly-general code-generating patterns to produce initially unoptimised output, and then attempt to remove unnecessary instructions; while a human would not have this generality - because the human knows more about the specific problem - and the "first-cut" of code he/she writes is already more specific than the compiler's.
(Not that I'm against compilers in general - I would very much like them to generate better code, but for that to happen there is likely going to have to be large changes in how they're written and how the whole process of compilation is thought of. Trying to make a compiler "think" like a human is a good first step...)