Related articles |
---|
Re: Writing fast compilers... RS/6000 roger@gimli.inmos.co.uk (1991-08-16) |
Re: Writing fast compilers... RS/6000 pardo@gar.cs.washington.edu (1991-08-17) |
Re: Writing fast compilers... RS/6000 pcg@aber.ac.uk (1991-08-19) |
Newsgroups: | comp.compilers |
From: | roger@gimli.inmos.co.uk (Roger Shepherd) |
Keywords: | optimize |
Organization: | INMOS Limited, Bristol, UK |
References: | <1991Aug15.010352.1@watt.ccs.tuns.ca> |
Date: | 16 Aug 91 08:06:22 GMT |
[From comp.arch -John]
In article <1991Aug15.010352.1@watt.ccs.tuns.ca>,
macdonaldk@watt.ccs.tuns.ca writes:
|> An overstatement, I think. Optimizing compilers are not going to
|> produce as much improvement on well written code as they will on student
|> first attempts, because the common subexpressions have be done in
|> source, the invariant stuff is out of loops, the loops are unrolled, the
|> register type has been used here and there... all by a one pass code
|> generator called a programmer.
Well, it depends on what you mean by ``well written code''. I think there are
very good arguments that say that good code contains common subexpressions,
contains rolled loops, etc. The code is clearer, earier to maintain etc. Also,
a compiler can often do a better job if the code is in this form than a
programmer can do by putting it into a more obscure form. Indeed, this is so
much the case that at least one book on ``How to write programs in FORTRAN for
supercomputers'' explicitly says:-
don't eliminate common subexpressions
(and one or two other surprising things that I forget now).
I would rather have a compiler which let well-written (:-) straightforword
code run very fast than have to produce obscure (and often machine-dependant)
code in order to achieve the same performance.
Roger Shepherd, INMOS Ltd JANET: roger@uk.co.inmos
1000 Aztec West UUCP: ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury INTERNET: roger@inmos.com
+44 454 616616 ROW: roger@inmos.com OR roger@inmos.co.uk
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.