Newsgroups: | comp.compilers |
From: | cliffc@rice.edu (Cliff Click) |
Keywords: | performance, assembler |
Organization: | Center for Research on Parallel Computations |
References: | 93-10-104 |
Date: | Wed, 27 Oct 1993 16:47:31 GMT |
elliottm@csulb.edu (Mike Elliott) writes:
> Folk Theorems
>[assembler code is 1) faster and 2) smaller than compiler code]
I should know better than to jump into such a flame-inducing question as
this, but here goes:
1) Sometimes compilers are better than humans (Assembly):
Compilers do all their optimizations all the time.
Compilers don't make mistakes (although compiler writers do :-).
Compilers can take the time and effort to look over the entire program,
or at least really big chunks of it.
Common examples: Compiling Fortran, C/C++,etc to a modern RISC (Mips,
Alpha, RS/6000, etc).
2) Sometimes humans (Assembly) are better than compilers:
Compilers only know what compiler writers teach 'em;
other humans may know that for this problem instance an otherwise
illegal transformation is legal.
Various compiler optimizations are geared toward regular register and
instruction sets; compiler writers have not learned how to handle well
the irregular register sets of some machines.
Compilers solve a particular problem: translating a HLL to machine code.
Sometimes humans want to solve a different problem (i.e., knowing the
EXACT number of cycles a particular stretch of code takes so we can
count on it being done before the next interrupt).
Common examples: squeezing the last drop of performance out of a Cray,
making an i860 do anything with it's pipeline, writing
hard-real-time code.
Cliff
--
cliffc@cs.rice.edu -- Massively Scalar Compiler Group, Rice University
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.