On 25.12.2012 12:40, Michael Van Canneyt wrote:
On Tue, 25 Dec 2012, Sven Barth wrote:
On 25.12.2012 12:13, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
>From what I remember, the problems you (and everyone else) experience
with smartlinking and so on are largely due to the GNU linker being
slow and memory hungry.
AFAIK there are significant differences in parsing and code producing
too.
Last time I checked on Windows with the internal FPC linker Delphi 7
compiled
and linked about 10 times as fast as FPC.
AFAIK Delphi's command line compiler does not allow you to skip the
assembling and linking phase, so the fairest comparison would be to
compare the compilation of a single unit as there the linking phase is
skipped. If Delphi is still better there then there are two
possibilities: improve the internal assembler or the parser/code
generator. Please keep in mind though that FPC's code generator is
written in such a way that the backend can be switched rather easily.
As we learned with the developer's blog entries about Delphi XE2 this
wasn't the case with Delphi XE and older. So it could be that you can
never reach the speed of Delphi 7's compiler as FPC is more portable.
Which is why I wrote that limiting the number of CPUs/Platforms would be
the obvious optimisation, but one which is incompatible with FPC's goals.
It would not only be limiting the amount amount of CPUs/Platforms. As
long as at least two CPUs exist that use the compiler's current backend
system it can't be optimized (at least not in that sense). You'd need to
basically bring the code generator back to a pre-1.9 state to gain
significant performance with reducing the number of target CPUs.
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
