Related articles |
---|
Speedy compilers abbottk@earthlink.net (Kirk Abbott) (1998-11-06) |
Re: Speedy compilers janusz.szpilewski@alcatel.pl (Janusz Szpilewski) (1998-11-15) |
Re: Speedy compilers mwolfe@pgroup.com (1998-11-19) |
Re: Speedy compilers jcrens@magicnet.net (Jack W. Crenshaw) (1998-11-19) |
Re: Speedy compilers toon@moene.indiv.nluug.nl (Toon Moene) (1998-11-21) |
Re: Speedy compilers joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-11-24) |
Re: Speedy compilers andrewf@slhosiery.com.au (Andrew Fry) (1998-11-24) |
Re: Speedy compilers bernecky@acm.org (Robert Bernecky) (1998-11-24) |
Re: Speedy compilers icedancer@ibm.net (1998-11-30) |
Re: Speedy compilers janusz.szpilewski@alcatel.pl (Janusz Szpilewski) (1998-11-30) |
Re: Speedy compilers amitp@theory.stanford.edu (Amit Patel) (1998-12-10) |
[12 later articles] |
From: | Toon Moene <toon@moene.indiv.nluug.nl> |
Newsgroups: | comp.compilers |
Date: | 21 Nov 1998 12:05:48 -0500 |
Organization: | Moene Computational Physics, Maartensdijk, The Netherlands |
References: | 98-11-047 98-11-086 98-11-089 |
Keywords: | performance, practice |
mwolfe@pgroup.com (Michael Wolfe) wrote:
> > So compile speed is a very important factor and compiler designers
> > should treat it seriously...
>
> One lesson I learned from too many years in graduate school and many
> more in industry is it is commercially infeasible to try to sell a
> slow compiler. Multiflow had a wonderful, highly optimizing,
> well-structured, but slow compiler, and it was a factor in losing
> machine sales.
I humbly disagree with this - or rather, the "explanation" behind it.
Of course it's hard to sell compilers which take an inordinate amount
of time to produce optimised code. However, that doesn't necessarily
mean that you shouldn't put some effort in optimisation. The nicest
counter example I recall is a 350 line FORTRAN routine that took 3:30
minutes to compile on my NeXTStation with the g77 as originally
released in February '95. After we found all shortcomings in the
sub-array-size computation, loop invariant code motion and induction
variable reduction/elimination, the compile time dropped to 36
seconds. The reason ? The subsequent optimisation passes had far
fewer insn's to worry about :-)
--
Toon Moene (mailto:toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.