Re: Speedy compilers

Andrew Fry <andrewf@slhosiery.com.au>
24 Nov 1998 22:23:28 -0500

          From comp.compilers

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)
Re: Speedy compilers mfinney@lynchburg.net (1998-12-13)
Re: Speedy compilers eclectictech@usa.net (1998-12-18)
[10 later articles]
| List of all articles for this month |
From: Andrew Fry <andrewf@slhosiery.com.au>
Newsgroups: comp.compilers
Date: 24 Nov 1998 22:23:28 -0500
Organization: Hilton Hosiery Company
References: 98-11-047 98-11-091
Keywords: performance

Jack W. Crenshaw wrote:
> Ever since their first introduction of Turbo Pascal 1.0, for CP/M
> machines, Borland has been noted for writing blindingly fast Pascal
> compilers. That first version was orders of magnitude faster than any
> other CP/M Pascal. The others were basically ports from minicomputer
> systems, and one could easily go for lunch while waiting for a
> compilation. Turbo compiled small programs before you could get your
> finger off the "C" key.


It's nice to see such an enthusiastic fan of Borland/Inprise! I use
Delphi a lot and like it very much (as a PC application development
environment) - particularly the reasonably strong typing and usable
object model.


But I'm inclined to agree with our moderator, speed comes from not
doing a lot of the hard work :) The only code optimizations I see it
doing regularly are; constant folding; strength reduction; and dead
code removal.


Now if they extended it to include common sub-expression and loop
invariant code recognition, I would expect to see much faster and
slightly smaller binaries. I for one would be very happy to see an
option for "optimize the life out of it - I don't care how long it
takes."


Andrew Fry.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.