[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