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] |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.