Comparison FPC 2.2 - Delphi 7.

MSEide aps\ide\mseide.pas without database support: Compile time FPC: 17.9s Delphi: 1.28s
Exe size FPC: 2.27MB Delphi: 1.87MB

One button MSEgui program apps\demo\demo.pas
Exe size FPC: 519KB Delphi: 456KB

All MSE *.o,*.ppu and *.dcu files deleted before compiling.

System:
win2000, AMD Athlon XP 3000+, 1GB RAM

Source:
https://mseide-msegui.svn.sourceforge.net/svnroot/mseide-msegui/trunk

Commandline FPC:
\fpc\svn\fixes_2_2\compiler\ppc386.exe -O2 -CX -XX -Xs -B -Fi..\.. \lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\.. \lib\common\kernel\i386-win32 -Fu..\..\lib\common\image -Fu..\.. \lib\common\widgets -Fu..\..\lib\common\designutils -Fu..\.. \lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\.. \lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\.. \lib\common\serialcomm -dmse_withoutdb -omseidefp.exe mseide.pas

Commandline Delphi7:
dcc32 -B -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\.. \lib\common\kernel\i386-win32 -U..\..\lib\common\image -U..\.. \lib\common\widgets -U..\..\lib\common\designutils -U..\.. \lib\common\sysutils -U..\..\lib\common\editwidgets -U..\.. \lib\common\dialogs -U..\..\lib\common\regcomponents -U..\.. \lib\common\serialcomm -Dmse_withoutdb mseide.pas

Martin

Op Wed, 4 Jul 2007, schreef Martin Schreiber:

Can you repeat on Win32 to see how much the internal linker helps? (Expected are minor savings in size and large savings in compile time.)

Daniël

It is already on Win2000.

Jonas

I think Daniel meant 'retry on windows with internal linker enabled' :-)

Michael.

I dont see an -Xe so the internal linker schould be enabld schouldnt it ??

Christan

Martin Schreiber wrote

Comparison FPC 2.2 - Delphi 7. MSEide aps\ide\mseide.pas without database support: Compile time FPC: 17.9s Delphi: 1.28s

How many lines of code ?

Micha

Linking time is about 1 second. Whole run with -Xe 21.3s.

Martin

185'578 lines.

Exe size with -Xe = 2.96MB

Martin

For me the times were 19.1 sec vs. 6.5 sec. Executable sizes are similar. FPC is slower indeed (undoubtedly, even), but factor 15 seems a lot; I think it's more like factor 4.

Micha

From: "Martin Schreiber"

-XX and -CX are useless on Win32. Internal linker always do smartlinking and external linker does not do it.

Try to pass -g- option to see if compile time will be reduced.

Yury.

The main reduction in compile time would probably come from using - O-1 -Ooregvar instead of -O2. I don't think the resulting code will be much slower either in most cases.

Jonas

Jonas Maebe wrote

The main reduction in compile time would probably come from using -O-1 -Ooregvar instead of -O2. I don't think the resulting code will be much slower either in most cases.

No, the main reduction is not outputting anything to console: from 18.5 sec to 15.9 sec vs. 18.5 sec to 17.5 sec.

I used 'compile-fpc | grep compiled'. Where compile-fpc is a batch file.

Micha

From: "Micha Nelissen"

I think it is because you run compilation for the second time and files were in cache.

Here mu number for the second run without deletion of compiled unit files (to ensure that source files are cached):

FPC with -O2: 14.7s;
FPC with -O-: 11.4s;
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.

Yury.

Yury Sidorov wrote

> I used 'compile-fpc | grep compiled'. Where compile-fpc is a batch file. I think it is because you run compilation for the second time and files were in cache.

No, I've run it several times, it's repeatable.

I am running in VMWare in a network drive though. I guess windows doesn't cache network drives and that's the difference (for delphi mainly, it seems).

Here mu number for the second run without deletion of compiled unit files (to ensure that source files are cached):

Does Delphi really rebuild all units, then ?

Micha

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.

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.

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.

And as for Delphi being fast - well, my daytime job projects require several minutes for Delphi to crunch through them. I've had Delphi hang up on me more than once for 15 minutes on simple projects with complex dependencies... All depends on what you haven't seen that happening with FPC yet. It's slower, yes, but it's more consistent in it's slowness.

Michael.

No, it does not.

Michael.

Of course it does do a decent make process.

But for me it does a "link" when I press F9 just to restart the program again when debugging. Why is this necessary ? (Delphi just start the program here.) or am I doing something wrong ?

-Michael

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

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.

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.

I had problems with the delphi compiler too, but only in odd ball projects (activex components and the like). Not in plain pascal code.

That's exactly the reason. When designing some part, you can always choose two of the three goals portability, maintainability and speed. Usually, you can't get all three. Since FPC is still reasonable fast, I don't consider this as really important. If it is, we can concentrate on a multithreaded compiler.

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

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.

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.

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

Agree fully, but then we should communicate that, (and point people to the profiler) and not blame it on portability beforehand.

Martin Schreiber wrote

Compile time FPC: 17.9s Delphi: 1.28s Exe size FPC: 2.27MB Delphi: 1.87MB

Contrary to most others, my analysis is the following:

It's really great that fpc now generates binaries of competitive size with the Delphi ones, and the build size is IHMO good for a software this big, and much better then it used to be.

The fact that Delphi's compile time is excelent doesn't mean that ours isn't good.

Try compiling a software this big written in c++ =) You can go to the cinema and come back that it will still be compiling.

Delphi 7 -B: 1.28s 1'964'544B

FPC 2.1.5 -O2 -CX -XX -Xs -B: 17.8s 2'384'884B FPC 2.1.5 -g- -O2 -CX -XX -Xs -B: 17.8s 2'384'884B FPC 2.1.5 -Xe -O2 -CX -XX -Xs -B: 21.2s 3'114'496B FPC 2.1.5 -O1 -CX -XX -Xs -B: 16.7s 2'517'492B FPC 2.1.5 -O- -CX -XX -Xs -B: 15.1s 2'574'836B

FPC 2.0.5 -O2 -CX -XX -Xs -B: 48.9s 2'566'144B FPC 2.0.5 -O2 -Xs -B: 17.9s 2'725'888B FPC 2.0.5 -O1 -Xs -B: 16.6s 2'780'672B FPC 2.0.5 -O- -Xs -B: 15.6s 2'865'152B

Martin

I profiled it some time ago and the compile time is simple spread over the compiler. Only two procedures consumed a lot of time: fillchar and move. I added the fastmove code at this time because we spend at least some time in move.

In general, we loose there and there 1-2 percent and at the end we're 5 times slower. Just start with the scanner: we support macro replacements, this requires an additional symtable look up for every symbol. Continue with PPU loading: we check for endianess when loading, requiring additional code. We write two or three files (.ppu, .o and .a) instead of one. Our register allocator is more sophisticated and scales better. We don't write the machine code directly but generate assembler first which can be written as listing, Delphi can't. Several debugging formats are supported, different assembler backends and so one.

None of these things is speed critical but it simply sums up.

Op Thu, 5 Jul 2007, schreef Martin Schreiber:

Well, now that you have MSEIDE working with FPC 2.2, you can switch to compiling without -B again.

Daniël

My experience is that FPC often crashes if not called with -B. And that is the reason why compile speed of FPC is important now. If I change one line in a unit I often have to compile the whole MSEgui to run the program again.

Martin

In that case the crash should be fixed. Speed will not be fixed... See the mail of Florian.

Michael.

Op Thu, 5 Jul 2007, schreef Martin Schreiber:

? Bug reports please :)

Daniël

Which was exactly my argument: The architecture.

Borland is focused on 1 CPU and 1 toolchain (their own), we are not, and we additionally support a lot of extra features which Borland does not support. All this shows in the architecture.

One of the reasons Florian profiled it was because Morfik had the same problem as Martin has now. He did some minor improvents (15% gain if I remember correctly ?)

As far as I know, in the end they solved it by creating a background thread which just continually compiles all code, so that when the user hits 'compile', it's already compiled, thus creating a 'fast' user experience...

Michael.

Crashes without -B happen with FPC 2.2 too.

I have the same opinion. Most important for me is the quality and the execution speed of the generated code by the compiler, second important is the size of the executable (I consider to use fpc for embedded systems). Having worlds fastest (perhaps assembler coded) compiler would be nice, but I think you developers (thank you for the fantastic compiler BTW) should focus on code generation and useful language extensions.

Regards, Bernd.

Daniël Mantione wrote

> Crashes without -B happen with FPC 2.2 too. ? Bug reports please :)

Only if you accept MSEgui as a testcase. It would use days or weeks for me to isolate the problems with my limited knowledge of the compiler internals.

Martin

For build related crashes it is accepted if it can be reproduced by a few simple steps like get this source, compile with that command, touch that file, rebuild.

Florian Klaempfl wrote

For build related crashes it is accepted if it can be reproduced by a few simple steps like get this source, compile with that command, touch that file, rebuild.

Indeed. At least Peter and I have already fixed quite a few MSEIde- related build crashes which were reported this way iirc.

Jonas

Florian Klaempfl wrote

I profiled it some time ago and the compile time is simple spread over the compiler. Only two procedures consumed a lot of time: fillchar and move. I added the fastmove code at this time because we spend at least some time in move.

What did you do to profile it? Is it something that can be easily repeated?

It would be nice to have an automated profiling system to run regularly just to keep tabs on things.

If a batch profiling job could be done on the compiler with the results placed on freepascal.org it may
prove an incentive for people to participate in speeding things up.

Using valgrind/calltree. Easily is relative, it takes some time.

As you will have supposed I was experiencing this with Lazarus. Maybe this is a Lazarus problem, but even if Lazarus thoughtlessly does a "make" with unmodified sources, IMHO, the make should no call the linker.

-Michael

If you trust Lazarus to make the right decision when determining if something is changed, then go to Project -> Project Options -> Miscellaneous and uncheck "Always build (even if nothing changed)".

Vincent

As you will have supposed I was experiencing this with Lazarus. Maybe this is a Lazarus problem, but even if Lazarus thoughtlessly does a "make" with unmodified sources, IMHO, the make should no call the linker.

-Michael

Make is not used, unless you rebuild lazarus.

I see.

-Michael

If you trust Lazarus to make the right decision when determining if something is changed, then go to Project -> Project Options -> Miscellaneous and uncheck "Always build (even if nothing changed)".

I see,

Thanks,

-Michael

Make is not used, unless you rebuild lazarus.

Michael.

I erred, sorry. Since I deleted all *.ppu files in the FPC and MSEgui source trees the FPC 2.2 compiler crashes without -B vanished. Good work, thanks. :-)

Martin