[fpc-devel] Comparison FPC 2.2 - Delphi 7

Daniël Mantione daniel.mantione at freepascal.org
Thu Jul 5 09:30:11 CEST 2007



Op Thu, 5 Jul 2007, schreef Marco van de Voort:

> > On Thu, 5 Jul 2007, Yury Sidorov wrote:
> > > D7:            1.6s.
> > > =

> > > Results are sad :( It is a good reason to find out why FPC is so slow=
 even
> > > without optimizations. Linking time is less then 1s, so it is not slo=
w.
> > =

> > Last I heard, the Delphi compiler is written in assembler, and is for 1
> > CPU only, which means they can do a lot of optimizations. FPC has a more
> > general architecture and therefore is not "optimal" in terms of speed.
> =

> Afaik Delphi beyond 1 was never written in Assembler, but C++. TP (and th=
us
> maybe D1) were in assembler.

Borland's compiler is written in C++. Speed critical parts are indeed =

assembler, which suggests good optimization rather than bad =

maintainability. However, there are signs of bad maintainability of the =

Borland compiler. Turbo Pascal was a fully assembler written compiler, =

which is probably the reason this compiler was not ported to 32-bit.
 =

> And IMHO the portability argument is bogus without research. I have some
> real doubts that this is the issue, since nearly all of the key parameters
> (memory manager, system requirements) are the same.
> =

> I rather expect a problem in ppu searching and loading etc.

Could be. However, there are several things in the portability can are =

speed expensive. For example, directly generating assembler code out of a =

call node is much faster than doing all the complexity with the =

paralocations.

However, the paralocations make implementing calling conventions easy and =

allows cpu independend code generation of the call node.
 =

> > Why do you think Borland has such a hard time supporting new platforms
> > (provided they spend time on it at all) ? They would have to rewrite th=
eir
> > compiler practically from scratch. For FPC, adding a new CPU is not so
> > much work, as it is designed for this.
> > =

> > So, the first reason that FPC is slower is its more general architectur=
e. =

> > Speed is the price you pay for this.
> =

> Yes. But that accounts for maybe 10-40%, at best.
>  =

> > A second reason for FPC being slower is that the compiler has to search
> > 2-3 times more files than Delphi (.ppu, .o - in several casings on linux
> > etc). With windows being the slow animal that it is, this hits FPC hard.
> =

> That's what I suspect too, also we have by default a way larger number of
> search directories, and we search for .inc files too. =

> =

> But that is just a hunch. Afaik there is simply no real data (except maybe
> in Peter's head, since he afaik did the most recent profiling when he
> implemented the internal linker).
> =

> So we can be short about this issue: want to improve? Start measuring, the
> compiler is just a bloody pascal program.

During the 2.1 cycle, very little attention was paid to the speed of the =

compiler itself. This is because the compiler is fast enough for our =

needs.

Dani=EBl


More information about the fpc-devel mailing list