[fpc-devel] Comparison FPC 2.2 - Delphi 7

[Daniël Mantione]

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 slow.
> > 
> > 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 thus
> 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 their
> > 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 architecture. 
> > 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ël