On 01/13/2010 02:37 AM, Per Jessen wrote:
Anders Johansson wrote:
On Tue, 2010-01-12 at 23:30 +0100, Per Jessen wrote:
Hand-optimized assembler will _always_ beat the compiler
That is a myth which even very good assembly programmers can only live up to in small inner-loop type segments. A good optimising compiler can do global optimisations that a human would find extremely difficult to do.
No myth at all. Perhaps you haven't met many very good assembler programmers? It's not really a topic I have a desire to debate (I know from experience that I am right).
The main reasons for _not_ using assembler are productivity and maintainability, but when speed is paramount, hand-optimized assembler will _always_ beat the compiler.
/Per Jessen, Zürich
Per, try to handwrite assembler code in IA64 :-).
While I would disagree with "_always_ " there are times when the
optimizers don't do a good job either. The C div() function is a pain,
and certainly, when you have numbers where you know certain properties
about those numbers you can do significantly better. div() is sometimes
included as a builtin.
Just to add to Anders' comments from my Alpha chip background. We took
the output instruction stream from the compiler, broke it up into "basic
blocks" then reordered the instructions based on latency tables and
other criteria to reduce stalls and improve parallelism. We did not for
both C code as well as for the assembler. This is one of the things that
the Intel compiler does.
But, my bottom line here would be the same as Per Jessen's. In his
specific case, I would stick with assembly code.
--
Jerry Feldman