Re: Speedy compilers (Rudi Ziegaus)
18 Dec 1998 12:17:44 -0500

          From comp.compilers

Related articles
[9 earlier articles]
Re: Speedy compilers (Janusz Szpilewski) (1998-11-30)
Re: Speedy compilers (Amit Patel) (1998-12-10)
Re: Speedy compilers (1998-12-13)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (Jeff Jackson) (1998-12-18)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
[1 later articles]
| List of all articles for this month |

From: (Rudi Ziegaus)
Newsgroups: comp.compilers
Date: 18 Dec 1998 12:17:44 -0500
Organization: Bingo (Buergernetz Ingolstadt eV)
References: 98-11-047 98-11-091
Keywords: Pascal, performance

On 19 Nov 1998 23:24:30 -0500, "Jack W. Crenshaw"
<> wrote:

>> Does anyone have any idea as to why the Delphi 3.0/4.0 compiler is so
>> blindlingly fast ? On my last crude check it was approaching 800
>> KLOC/minute. Apart from lcc does anyone know of any other fast
>> compilers for C or Java.
>Short answer: Delphi uses Pascal, other compilers are C or C++.
>Because it is easy to implement in a recursive-descent parser, Pascal
>is much faster to compile. Note that it also has no preprocessor, and
>therefore no #includes.

Sorry to correct: Delphi has include files {$I}, but they are not used
very much. It's more a mechanism to include source partns and not for
definitions. I personally have not used the include directive for more
that 6 years. In most cases it's better to use a unit for this.

>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.
>Since then, Borland has managed to speed up each successive release by
>at least a factor of two, if not moreso. One has to feel that there
>must be a knee in the curve somewhere, where more speed is hard to
>come by, but they don't seem to know that. Last I heard, Delphi I was
>supposed to compile at 300,000 lpm. I'm sure v4.0 goes even faster.
>Remember that there are at least three parts to what we normally call
>compiling. I'm not talking front end/back end, or scan vs. parse.
>I'm talking about: (1) turning the source code into object code, (2)
>linking object files, and (3) including library files.
>Aside from having a fast compiler for part (1), Borland has always
>excelled in (2) and (3), as well. Their first compiler made it easy,
>by not allowing separate compilation, and including the entire library
>in every program. Since then, they've gotten much more sophisticated.
>The combination includes Object Pascal Units, which can be
>precompiled, and yet selectively linked. By that I mean, if you only
>call one procedure from a unit, that's all that gets linked. Second
>is their secret weapon, a linker that works very differently from
>Microsoft's, and links at the speed of light.

Yep, only too true. This speed is possible since it it a native format
of Borland, which changes each version, so you can't mix units from
different Delphi versions. Object files under 16 bit were so strangely
defined that one couldn't optimize without great loss of performance.
For example, itf one function in an obj file was used, the whole
object had to be linked into the exe/lib file.

>[It's not all that hard to write a fast C compiler. Turbo C was very
>fast, much faster than Wizard C from which it was adapted. -John]

I think that one important answer has not been given why Turbo Pascal
is so fast. Until version 1 of Delphi the whole compiler part was
written in assembler.

Because of that you don't need so much memory for the compiler and you
can dedicate more memory to symbol tables, unit headers, etc.

Nowadays I don't know. I know however that Delphi and C++ share a
common backend, but maybe the frontend is still written in assembler.

I believe Delphi keeps all debug symbols in memory, that's why you can
include Turbo-Debugger-infos in the file. If you look at an exe file
compiled with delphi with and without debug infos there's a huge
difference. The debug infos can easily surpass 1 MB in size.


Post a followup to this message

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