Question: A long, long time ago, in a galaxy far away, I used to write programs in Delphi, and then if I needed something to happen really fast, I'd write those routines in hand-written assembler. It produced much faster code than the compiler did.

But is this true **in practice** any more? Obviously hand-written assembler will always be at least as fast **in principle** as compiled high-level code. But CPUs have moved on a long way since those dark times. Now, if you were trying to optimize your assembler, you'd have to take into account ordering of instructions so they could be pipelined or run concurrently, the effect of branch prediction, and a million other things; and I suspect it's impossible to hold them all in human RAM simultaneously.

So does this mean that a decent (but not superhuman) programmer will these days produce faster code by writing C than by writing hand-written assembler, at least when coding for a modern CPU?

One other possibility that occurs to me. Does the optimization happen *before* the high-level language is turned into assembler, or afterwards? If it's afterwards... might it be faster to produce hand-written assembler, and then put it through the compiler's optimization process?

The question arose recently when I was writing some code for a programming challenge, where the essence of it was to produce a routine that should run as fast as possible on a Raspberry Pi. I would have been allowed to write it in assembler; but my guess was that carefully written C would be faster, even though a Pi processor isn't that sophisticated in 2014 terms.

To make the question more concrete and specific:

* Suppose you're wanting to write blazingly fast (integer) number-crunching code to run on a Raspberry Pi. You've written some very nice C code that runs as a tight loop to solve the problem. Is it worth hand-crafting it in assembler to speed it up, or will that in practice give you something less efficient?

Answer: 
To me it looks both answers given so far are correct. The answer depends, among other things, on the particular CPU architecture we're talking about. The more complex architecture is, the harder it is to write efficient ASM code by hand.

On one end of the spectrum are CISC cores such as x86. They have multiple execution units, long pipelines, variable instruction latencies per instruction, etc. In many cases ASM code that looks "clean" or "optimal" to a human isn't in fact optimal for a CPU and can be improved by using instructions or techniques from dark corners of processor manuals. Compilers "know" about this and can produce decently optimised code. True, in many cases emitted code can be improved by a skilful human, but with the right compiler and optimisations settings code is often already very good. Also, with C code at hand you won't need to re-optimise it manually for every new CPU generation (yes, optimisations often depend on particular CPU family, not only on instruction set), so writing in C is a way of "future-proofing" your code.

On another end of the spectrum are simple RISC cores, such as 8051 (or others *simple* 8-bit controllers). They have much simpler scheduling semantics and smaller instruction sets. Compilers still do a decent job of optimisation here, but it's also much simpler to write a decent ASM code by hand (or fix performance issues in emitted code).
Hand-written assembler is still faster than decent C code. If you knew how to write assembler you wouldn't believe what cruft some compilers generate. I have seen insane stuff like loading a value from memory and instantly writing it back unmodified (as recent as two years ago, I generally do not look at assembler output anymore). Here is an even more recent rant by Torvalds on a similar issue in gcc [lkml.org](https://lkml.org/lkml/2014/7/24/584).

However, even though hand-written assembler is still faster, it generally does not pay off. At the maximum, you'll want to write some very performance critical short routines in assembler. The rest is better left in C for portability.