Hi,

In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7 compatible again.
Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649): http://gitorious.org/mseide-msegui

As testcase I used compiling MSEide, all dcu's, ppu's and o's deleted before compiling.
System:
win2000, AMD Atlon XP 3000+, 1GB RAM

Command line Delphi 7:
dcc32 -B -D+ -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\..\lib\common\audio -U..\..\lib\common\opengl -U..\..\lib\common\report -U..\..\lib\common\db
-U..\..\lib\common\crypto -U..\..\lib\common\graphics -U..\..\lib\common\i18n -U..\..\lib\common\kernel\windows -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 -U..\..\lib\common\printer -U..\..\lib\common\ifi
-U..\..\lib\common\math -U..\..\lib\common\delphicompatibility -U..\..\lib\common\fpccompatibility mseide.pas

Result Delphi 7:
483086 lines, 6.72 seconds, 3396292 bytes code, 1217961 bytes data.

F:\proj\mseide-msegui\apps\ide>dir mseide.exe
Datenträger in Laufwerk F: ist win2000_F
Datenträgernummer: 5C58-C4EF

Verzeichnis von F:\proj\mseide-msegui\apps\ide

01.03.2013 17:22 5'062'144 mseide.exe

Command line FPC 2.6.2:
ppc386.exe -g -Xg -O2 -CX -XX -Xs -B -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\audio -Fu..\..\lib\common\opengl -Fu..\..\lib\common\report -Fu..\..\lib\common\db -Fu..\..\lib\common\crypto
-Fu..\..\lib\common\graphics -Fu..\..\lib\common\i18n -Fu..\..\lib\common\kernel\windows -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 -Fu..\..\lib\common\printer -Fu..\..\lib\common\ifi -Fu..\..\lib\common\math
-Fu..\..\lib\common\delphicompatibility
-Fu..\..\lib\common\fpccompatibility -omseidefp.exe mseide.pas

Result FPC 2.6.2:
489756 lines compiled, 84.6 sec , 3309520 bytes code, 2691084 bytes data

F:\proj\mseide-msegui\apps\ide>dir mseidefp.exe
Datenträger in Laufwerk F: ist win2000_F
Datenträgernummer: 5C58-C4EF

Verzeichnis von F:\proj\mseide-msegui\apps\ide

01.03.2013 17:24 6'026'259 mseidefp.exe

Martin

For a correct test, you should not enable debug information in FPC. Or enable generation of turbo debug information and the corresponding linker map in Delphi.

Otherwise you are comparing apples with pears, as -D+ in delphi does not do nearly the same thing as -g in FPC.

That said, it takes about 30 seconds on Linux on a laptop to do the same thing. Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
(A centrino - whatever all these numbers mean today)

Of this, about 8 seconds are spent in the gnu linker ld. Taking away smartlinking removes 10 seconds from the total time.

So, at least we can say with confidence that the linker takes a large part of the time.

I am not sure if the Windows version of FPC uses ld when smartlinking, so comparison should be done with caution.

On linux, there are a lot of getdents and stat calls: 823 getdents calls.
14611 stat calls.
So I'm sure there is room for some improvement there.

What I remember from windows 2000 is that FPC/ld/etc is several factors slower on the same hardware as when run under Linux.

Michael.

Forgot to say that this is done using the 64-bit, unoptimized version of FPC, which is probably slow when compared to the 32-bit optimized version of FPC.

Michael.

In our previous episode, Michael Van Canneyt said:

What I remember from windows 2000 is that FPC/ld/etc is several factors slower on the same hardware as when run under Linux.

Afaik the internal linker is default on windows since 2.2.0 ?

There are still some issues with external .a archives, which is why the makefiles afaik enable the external linker for the textmode IDE (libgdb)

Also when smartlinking ? I am not sure about this.

Michael.

In our previous episode, Michael Van Canneyt said:

I think that was one of the primary reasons for it even.

Before the internal linker, smartlinking lazarus (every unit in it) with LD could eat 1.5GB

On *nix, sections smartlinking remedied that somewhat, but on Windows not.

From an end user point of view comparison of compiletime with debug info is correct IMHO because one needs debug info for development.

with
ppc386.exe -O2 -CX -XX -Xs -B -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\audio -Fu..\..\lib\common\opengl -Fu..\..\lib\common\report -Fu..\..\lib\common\db -Fu..\..\lib\common\crypto
-Fu..\..\lib\common\graphics -Fu..\..\lib\common\i18n -Fu..\..\lib\common\kernel\windows -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 -Fu..\..\lib\common\printer -Fu..\..\lib\common\ifi -Fu..\..\lib\common\math
-Fu..\..\lib\common\delphicompatibility
-Fu..\..\lib\common\fpccompatibility -omseidefp.exe mseide.pas:

489756 lines compiled, 56.8 sec , 3309520 bytes code, 2691084 bytes data

F:\proj\mseide-msegui\apps\ide>dir mseidefp.exe
Datenträger in Laufwerk F: ist win2000_F
Datenträgernummer: 5C58-C4EF

Verzeichnis von F:\proj\mseide-msegui\apps\ide

01.03.2013 20:18 6'025'728 mseidefp.exe

On the same machine with OpenSUSE 12.2 and
ppc386 -O2 -CX -XX -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp.exe mseide.pas:
I had to kill the process after 10 minutes, 1GB is not enough to smartlink 32 bit MSEide. For 64bit MSEide 2GB are not enough for smartlinking.

ppc386 -O2 -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp mseide.pas:

495808 lines compiled, 64.8 sec
-rwxr-xr-x 1 mse users 7453980 Mar 1 22:10 mseidefp

ppc386 -O2 -g -Xg -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp mseide.pas:

495808 lines compiled, 102.9 sec
-rwxr-xr-x 1 mse users 7459160 Mar 1 22:14 mseidefp

Martin

Martin Schreiber wrote

Hi, In order to have a good benchmark for FPC

Expect the next release to be even slower.

Will it produce better code instead?

Martin

What means better? Faster? Less buggy? Smaller?

I did a quick test on win32, it seems to be a little bit smaller than 2.6.2:

02.03.2013 10:09 5.774.848 mseide.exe

Absolutely. I am not arguing with that.

But Delphi does not generate any real debug info with $D+. You need the actual units (dcu) to be able to debug.

You cannot debug anything with an external debugger unless you enable turbo debugging info.

With FPC you can use (well must) an external debugger. So FPC creates info readable by an external debugger.

If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work.

Therefor to compare what is actually comparable,
and by this I mean that both compilers perform the same tasks, you must enable generation of turbo debugging and the linker map info in delphi.

This means additional work for the Delphi compiler and therefor will slow down Delphi too.
(in fact quite a lot, if I recall my work with AQTime).

Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise.

Michael.

Michael Van Canneyt wrote

Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise.

On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too.

Martin

For i386-win32 maybe.

A compiler must be bug free anyway. ;-)

trunk.

It means faster and smaller, Delphi 7 produced code is smaller and faster than FPC 2.6.2 code. A compiler must be bug free anyway. ;-)

I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe

Compiled with which FPC version?

Martin

Surprise! :P

We don't try to respect backwards compatibility for nothing. ;)

Regards,
Sven

??? MSEgui compiles with trunk?

Martin

When you do, please send me the output of a strace -f

It will allow me to see what IO the Delphi/Kylix compiler does.

We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower.

(for example renaming all files to .pp takes off +/- 1 second here)

Nevertheless, I'd be interested in seeing the strace.

Michael.

Compiled with WPO and -O4 it starts and I can edit text and forms. Nothing more tested.

Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU.

In our previous episode, Florian Kl?mpfl said:

Better paralellize the compiler :-)

Am 01.03.2013 18:33, schrieb Martin Schreiber: > Hi, > > In order to have a good benchmark for FPC

Afaik Delphi 7 is closed source, so inherently worse than any version of FPC.

Cheers,
Vittorio

In our previous episode, Martin Schreiber said:

It is mostly unicodestring centric, so that shouldn't be such a surprise?

MSEgui has an own unicodestring manager on Linux which must be adapted to cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses some hacks with UnicodeStrings which must be adapted. I don't want to do the work before Unicode handling in FPC is finished and documented. And frankly, I don't believe in it anymore...

Martin

Clearly, you have not been watching SVN, because Paul Ishenin is currently integrating the native Object Pascal unicode string manager in trunk.

Michael.

Michael Van Canneyt wrote

If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work.

Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. A more apt comparison would be that we hired the painters to paint the outside of the house and one of them did the inside too because his tools require him to paint both sides of the walls.

In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case.

While the other one can paint only in one color and only buildings with one floor ;)

In our previous episode, Florian Klaempfl said:

I don't see why there would be more synchronization overhead than make?

In a parallelized compiler symtables etc. might be shared and this might require a lot of synchronization to prevent data corruption. With make, the different units can be seperated much better by a human than the compiler can do.

Not to mention the huge effort it would be to get the compiler parallelized internally.

So why not keep it simple and let the build system handle parallel jobs?

Henry

You cannot ignore the implementation details. Making abstraction of these details means ignoring the benefits that follow from these details:

It is exactly these details that allow FPC to support so many platforms, and why Delphi is stuck with Windows and remote compiling/debugging for MaCOS. Delphi does not even run on these platforms ! FPC does.

If you are - like Martin, I suspect - not interested in weird and exotic platforms then of course FPC's implementation choice and the attached consequences present you with a disadvantage because of these 'implementation details'.

But if you are interested in ARM, raspberry PI, MIPS and whatever there is out there, it is these implementation details that make FPC the only possible choice.

All this said:
You will not hear me claiming that there is no room for improvement in FPC. I'm sure there is. However, I do not think we'll be able to match Delphi's speed without sacrificing the main goal of FPC: to support as much platforms as possible.

So, proposals for improvement are most welcome.

Michael.

In our previous episode, Florian Klaempfl said:

Only if you want to avoid multiply used units to be only once in memory. IMHO if you are afraid of that, then don't do that :-)

Not to mention the huge effort it would be to get the compiler parallelized internally.

As said the first step can be relatively simple. Get rid of globals some more, and then only the parts before compile() needs to be changed. The rest more or less runs as is, and the linker remains single threaded after all compile threads have finished?

In our previous episode, Henry Vermaak said:

> I don't see why there would be more synchronization overhead than make? So why not keep it simple and let the build system handle parallel jobs?

I like autobuilding. IMHO that is a core attraction of unit based (modular) languages.

Manually maintaining dependencies between compilation units is stone-age.

Forking compilers on a by unit level instead of some meta level is typically slower because reading ppus takes a lot of time.

In theory, yes. In practice this is a huge effort. Just one example: inlining requires that the node tree of a procedure is copied. However, during copying the tree is annotated for proper copying. Bottom line: even if the compiler finished to compile a unit, the generated info is not read only.

Well, not to mention the goal of maintainability.

Michael Van Canneyt wrote

We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower.

Second time I hear this this week. Can we (in our own copies of FPC) change this to search .pas first? If so, where in the source?

Regards,
- Graeme -

Search for sourceext and pasext.

fppu.pas:           Found:=UnitExists(sourceext,hs);
fppu.pas:              Message1(unit_t_unitsearch,ChangeFileExt(sourcefn,sourceext));
fppu.pas:            fnd:=FindFile(ChangeFileExt(sourcefn,sourceext),'',true,hs);
globals.pas:       sourceext  = '.pp';
options.pas:      if FileExists(inputfilepath+ChangeFileExt(inputfilename,sourceext)) then
options.pas:        inputfilename:=ChangeFileExt(inputfilename,sourceext)
scanner.pas:               found:=findincludefile(path,ChangeFileExt(name,sourceext),foundfile);

Be careful when changing this, because the compiler will then also search for rtl/fcl/package source files with different names, which may result in nasty surprises.

Michael.

I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible.

AFAIK "*.pas" is Delphi compatible? ;-)

Martin

BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B.

Martin

Op Sun, 3 Mar 2013, schreef Martin Schreiber:

BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B.

I think you should focus your efforts on getting those bugs fixed, such as by submitting bug reports that allow reproduction of the problem with programs as simple as you can get them to show the problem.

It is completely unrealistic that FPC will get the same compiler speed as Delphi. FPC will become slower in the future for sure, because the compiler will execute more algorithms to generate better code.

Daniël

Same here :)

Do you mean compiling the compiler? If so than for real tests you SHOULD NOT compile the compiler by hand, but only through "make cycle" in the compiler directory or "make all" in the top level directory. This will ensure that the compiler is compiled correctly.

And yes, I know the problem with -B and it's likely related to unit loading. This normally happens only in more complex projects like the compiler. Though I've just managed yesterday to create a smaller example (by accident) that also chrashes. Maybe I'll find the problem and can fix it once and for all :)

Regards,
Sven

The problem is well known since a long time AFAIK. The answer we normally get when we report a unit handling related FPC crash is that FPC unit handling should be rewritten. I can't rewrite FPC unit handling myself because I have many other tasks. ;-)

Martin

No, I mean MSEide. MSEide is a more complex application than the compiler it seems. :-)

Martin

No, it's not (at least not in that sense ;) ), because the compiler triggers this error as well, when I compile it inside the IDE.

Regards,
Sven

A sure sign that you have fishy code :)
I have lots of code, and never ever experienced such a thing. I even can't remember when the compiler last gave me a problem; and I use it daily.

Most problems I experience today have to do with version management.

I'm sorry, but I do not share your focus on speed. I have many projects, some of them have more units than mseide does, and yet I never have to wait more than a couple of seconds. The only exception is the Lazarus IDE.

If you say that mseide only compiles with -B, I would suggest looking for strange dependencies inside mseide, if you want to reduce compile time...

I do not want to say that FPC does not need speed improvements, but I do suspect you will get faster results looking at removing the -B requirement from mseide...

Michael.

I checked again, time of FPC linking stage is about 2.5 seconds.

Martin

On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3, Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3): http://gitorious.org/mseide-msegui

Command line Kylix 3:
dcc -D+ -Aclasses=Classes -Adateutils=DateUtils -Afmtbcd=FMTBcd -Amaskutils=MaskUtils -Astrutils=StrUtils -U${DCUS} -I../../lib/common/kernel -U../../lib/common/kernel -U../../lib/common/audio -U../../lib/common/opengl -U../../lib/common/report -U../../lib/common/db -U../../lib/common/crypto -U../../lib/common/graphics -U../../lib/common/i18n -U../../lib/common/kernel/linux -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 -U../../lib/common/printer -U../../lib/common/ifi -U../../lib/common/math -U../../lib/common/delphicompatibility -U../../lib/common/fpccompatibility mseide.pas

Result Kylix 3:
488041 lines, 4.40 seconds, 2762044 bytes code, 1220304 bytes data. -rwxr-xr-x 1 mse users 5092836 Mar 3 18:16 mseide

Command line FPC 2.6.2:
ppc386 -O2 -g -Xg -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp mseide.pas

Result FPC 2.6.2:
495971 lines compiled, 89.3 sec
-rwxr-xr-x 1 mse users 7463712 Mar 3 18:19 mseidefp

Please note that smartlinking with FPC is not possible on that system because it has 1GB ram only.

Martin

In our previous episode, Michael Van Canneyt said:

I'm sorry, but I do not share your focus on speed. I have many projects, some of them have more units than mseide does, and yet I never have to wait more than a couple of seconds. The only exception is the Lazarus IDE.

No, I have also seen it with Indy and the JCL. In the JCL case I tried to isolate it even, (and managed to 3 or 4 units).

And over the years, that are not the only cases.

If you say that mseide only compiles with -B, I would suggest looking for strange dependencies inside mseide, if you want to reduce compile time...

No, afaik there is certainly a problem in the compiler. Afaik I heard devs that unit dependencies cycles with more than two units are not always detected clearly (and probably that implies some hidden interface-implementation dependencies?)

I do not want to say that FPC does not need speed improvements, but I do suspect you will get faster results looking at removing the -B requirement from mseide...

That's for sure.

Impressive.

Now that we've clearly established that FPC is slower than Delphi, and that you consider this a serious problem (which we, in fact, know since some time):

When can we expect to see some constructive proposals on how to improve the situation?

Michael.

I supplied the benchmark, more than 10 man years of development time. A good start, no? ;-)

Martin

First 10 m of a marathon done.

Florian Klämpfl wrote

First 10 m of a marathon done.

Is that 'miles' or 'meters'? ;-)

Regards,
- Graeme -

Sad. Instead of "fight", why not walking together?

IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's "defects".

Martin:
I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You are only showing the Delphi/Kylix speed is extremely superior (even knowing that Delphi do not is multiplataform and do not have the complexity that FPC has, AFAIK). One more thing: try do not thinking only in MSEgui in your thoughts, in your great ideas.
IMHO the MSEgui should be part of FPC, somehow, but...

FPC Team:
Try to hear Martin otherwise, because he is a great developer with great ideas.

Best regards,
Marcos Douglas

I am not so sure about this... I know nothing of dcc switches but he is comparing the compiler speed with a different set of features, it is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all optimization flags and it is expected that optimizing code takes time.

Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time!

FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas.

I am no fpc dev here, but patches are welcome I guess.

Jm2c
Vittorio

That's what I meant when I spoke "he is making a mistake in their approach of how to present FPC's "defects".

Marcos Douglas

Marcos Douglas wrote

Sad. Instead of "fight", why not walking together?

I'm not joining any "fight", simply wanted to know what the 'm' stood for.

I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements!

You said it yourself... most of us know nothing about compiler coding. So how are we supposed to propose improvements! All we can do is file bug reports on things we can duplicate, or highlight issues. This is what Martin is doing here.

4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately].

But let me repeat what you said earlier. Some of use know nothing about compilers coding, so not much we can do about it. The task falls squarely on the select few, but they have no interest in that. Optimization is boring work, compared to implementing the latest CPU target or language feature. I understand that fully. A great pity.

You are only showing the Delphi/Kylix speed is extremely superior

And Martin is just showing half the problem. The Delphi & Kylix compilers also produce executables that run 10+ times faster than what FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And don't even think of mentioning that faster hardware will mask the problem - it doesn't. I have a i7-2660K with high performance RAM and 450MB read speed SSD. I noticed a > 10+ times difference in running executables on my hardware.

And comments from Florian like "expect FPC to get even slower by the next release" doesn't help much.

Nobody expects FPC to beat Delphi or Kylix performance, but FPC degrading its speed (compile time and executable run time) year-on-year is not a good sign for the long run.

Anyway, this is nothing new. I mentioned this long ago, and made my peace with it. I have to cherish the fact that FPC is luckily still faster that C/C++ compilers.

Regards,
- Graeme -

I know. I just used the last mail on this thread -- in that case, your mail. Sorry.

Yes, I agree... but I feel a "fight" between Martin and FPC Team, don't you agree?

I feel the same... but we can not force people who work for free to do
tasks that are not important to them.

Again I repeat: I agree with you.
The Pascal is known because it is simple, elegant, [,,,] and FAST.

And comments from Florian like "expect FPC to get even slower by the next release" doesn't help much.

Yeah... very sad.

Nobody expects FPC to beat Delphi or Kylix performance, but FPC degrading its speed (compile time and executable run time) year-on-year is not a good sign for the long run.

Many many "improvements" trying to following Delphi, Java, whatever.

Anyway, this is nothing new. I mentioned this long ago, and made my peace with it. I have to cherish the fact that FPC is luckily still faster that C/C++ compilers.

For the time being... :)

Marcos Douglas

Please note that Delphi/Kylix produce both smaller and faster code than FPC in the testcase, they do full optimisation by default. Quality of the produced code is another goal of the comparisons.

MSEide sizes
------------

Delphi 7: 5'062'144
FPC 2.6.2 Windows with smart linking: 6'026'259
Kylix 3: 5'092'836
FPC 2.6.2 Linux without smart linking 7'463'712
(it can't smartlink with 1MB ram only)

Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted.

Martin

Op Sun, 3 Mar 2013, schreef Marcos Douglas:

That FPC is slower than Delphi is a result of many concious decisions:
* FPC has a lot of passes through the node tree - allows more features and transformations
* FPC has a more layered code generation (hlcg, cg, cpu specific overrides) - allows manu CPU architectures, JVM and more
* FPC has an advanced register allocator. Allows speedy code and many CPU architectures.
* FPC has external debug information. Due its nature, this debug info requires processing power.

As these are concious decisions, there is no quick fix. This doesn't mean no attention has been made to the compiler speed, many efforts have been put into profiling and optimizing the algorithms. For the rest, one has to accept FPC as it is. If FPC was inferior to Delphi, we would not have had this discussion.

Further, global bennchmarks of "my million line program takes long to compile" are not helpfull at all in diagnosing performance problems. (Or bugs, or other issues).

Daniël

While I tend to agree in general, you would be surprised at the impact it has.

I tossed an idea to the core group to speed up PPU loading, and it was immediatly torpedoed on solid technical grounds. The cross-platform argument is not easily circumvented. Could be that I disclosed another reason why Delphi remains intel-only for development :)

Michael.

What "defects" exactly? I just see random data dumped on the mailing list, data produced from a random project using random compiler switches...

Martin made a point that delphi7 is faster better and whatever than fpc... so what?
Don't use fpc if you don't like it, or send patches to improve it ;)

jm2c
Vittorio

Florian Klaempfl wrote

In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case.

I suppose the (high level) synchronization will be rather complex and eat performance.

The low level threadvar implementation is known to be improvable. AFAIR, it uses library calls as well in Windows as in Linux while the appropriate C compilers use segment registers (on x86 / x86-64) which are documented in Linux and undocumented in Windows and supposedly a lot faster.

OTOH, are Theradvars necessary to be used very frequently (i.e. more than when creating thread-specific objects, that then can be used to access the thread specific data) ?

-Michael

The "(on x86 / x86-64)" disqualifies your argument for use. The solution must work on ALL platforms...

BTW. threadvars in FPC are done in the same way as in Delphi, with TLS.

Michael.

Michael Van Canneyt wrote

The solution must work on ALL platforms...

Of course.

I don't remember ever having seen a system (Windows, Linux, x86, ARM, NIOS (similar top MIPS) ) where the C compiler does a library call when accessing a threadvar. Usually a register is dedicated for this purpose that is loaded with a thread specific value by the OS. I do know C compiler implementations that don't support threadvars at all and thus are unable to support FUTEX and with that low level thread synchronization is a lot slower as always a userland/system switch is necessary. Here hardware (atomic instructions) and the OS implementation (e.g. "Atomic Region" to overcome such limitations for userland) comes into play.

I remember from a discussion some years ago that fpc uses a (supposedly arch/platform depending) library call with any access to to a threadvar instead of using the appropriate (arch/platform depending) register. But I did not recheck recently.

-Michael

We use pthreads on non-windows, and GetTLS/SetTLS on Windows.

Michael.

In our previous episode, Graeme Geldenhuys said:

And if miles, what miles?

In this case I would take the Scandinavian Mile, and skip next years marathon too:

http://en.wikipedia.org/wiki/Scandinavian_mile

On Mon, Mar 4, 2013 at 9:26 AM, Vittorio Giovara <

wrote: Don't use fpc if you don't like it, or send patches to improve it ;)

http://programmers.stackexchange.com/questions/68740/whats-the-canonical-retort-to-its-open-source-submit-a-patch

Michael Van Canneyt wrote

We use pthreads on non-windows, and GetTLS/SetTLS on Windows.

Thus the situation is as it was when we discussed this some years ago: a library call with each access to a threadvar, making fpc a lot slower that the C compiler (Microsoft and GNU, no idea about other brands) on that behalf (that might nob be very relevant in real life) .

(BTW: a similar discussion arises with any thread-synchronization primitive AFAIK here dynamic library calls are done while an arch-depending Futex/Mutex implementation directly in the RTL _could_ be done. But here, a C user (Linux) would do the same library call to pthreadlib "mutex...()" which does "Futex"if available in that arch, and "Mutex" if not. )

-Michael

I just add all the objects to a variable in a Makefile.

The result is that I have a 27000 line c library that compiles in *half* the time it takes to compile a 4000 line lazarus program because my c lib can be built with make -j 9.

Henry

You probably might know, I am the author of MSEide+MSEgui: http://sourceforge.net/projects/mseide-msegui/

In MSEgui development I am happy if users report what they need in their daily work and what is inconvenient in current MSEgui implementation. I then try to examine the problem, find out how it can be solved and implement an universal solution based on what I learned from the conrete "real world example". I do not expect that users provide patches, reproducible testcases are enough. If the users provide patches there is a big risk, that they fix their current problem only instead to find an orthogonal improvement. And the quality of the code maybe is not always the best. ;-)
Please read the MSEide-MSEgui mailing list archive in order to check how things are handled in MSEgui.

With the MSEide Delphi/Kylix/FPC comparison I provide a real world testcase which the FPC team can use to improve their product. If the FPC team don't want to do so or think it is not necessary or it is no fun then I have to accept it and I will accept it.
But from time to time I will repeat the comparison in order the facts will not get forgotten.

Martin

In our previous episode, Henry Vermaak said:

I'm not exactly sure what this proves. The C situation is not equivalent to the Pascal situation, the latter trying to make sure all (Pascal level symbols) are there before the linker.

Given your reputation, I suppose patches from you will not suffer from this problem.

Michael.

Op Mon, 4 Mar 2013, schreef Martin Schreiber:

Understood. What if your users submit issues that are fundamental to your UTF16-decision? For example shortstrings would be more compact and faster. I suspect you are not going to change MSEIDE to another approach.

It's the same here. Compiler speed is lower than Delphi due to design decisions, that cannot be easily altered. Optimization is always possible, but the low hanging fruit is gone, because as said, extensive time has already been spent into compiler speed.

Daniël

Marcos Douglas wrote

I know. I just used the last mail on this thread -- in that case, your mail. Sorry.

You should know better, and to never use any of my replies for something like that. I have no patience or sense of humour. ;-)

Yes, I agree... but I feel a "fight" between Martin and FPC Team, don't you agree?

No, and I don't desire it either.

I feel the same... but we can not force people who work for free to do tasks that are not important to them.

Correct.

Regards,
- Graeme -

You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Let me name some of the stuff which might count only 10% each (some more, some less) but in total makes FPC much slower:

- gcc compatible output format (*.ppu+*.o instead of one big ppu only usable with FPC)
- flexible assembler output (different assemblers supported, assembler listing output)
- flexible object file output (coff, elf, ...)
- portable ppus (regardless of the host system, ppus are bitwise equal. this means e.g. a lot of endian conversion checks and calls)
- class helpers
- operator overloading
- generics
- architecture agnostic node tree
- architecture agnostic constant handling (96 bit arithmetics)
- portable code generator
- support of bit packed data structures
- flexible debugging info output
- completely written in a high level language
- architecture agnostic symtable handling
- using the rtl heap manager, a non threadsafe heap manager would be probably slightly faster but do we want to maintain two full featured heap managers?
- using ansistrings, one could switch to zero passed char arrays but do we really want this?
- architecture agnostic handling of procedure parameter passing
- code page aware reading of input files
- different FPU types supported
- portable optimizer
- 32/64 bit assembler supporting all available instruction sets
- high level code generator layer for jvm support
- support of different pascal dialects
- portable and flexible file handling
- using classes instead of objects
- ...

And yes, the speed penalty of these features/properties often multiplies and is not only additive. Of course, this is all simplified but it should give you an idea where the factor 10 comes from. It is a lot of small things none of them really counting but in total it's a lot (exponential grow) and this makes it impossible to fix this without sacrifying a lot of FPC's power.

FYI: FPC 1.x is several times faster than FPC 2.x
FYI2: Last time somebody tried (years ago, -/+ year 2000), FPC compiled by Delphi was slower than FPC compiled by FPC.

My goal regarding the speed of FPC is: let Moore win. This means faster CPUs should make FPC faster than new features in FPC make FPC slower and this works for 20 years now. So nothing to worry.

Then something with your code is wrong. Or you hit some strange bottleneck, you should really profile your code.

.
.

It's questionable whether it should be responsibility of a compiler to provide efficient support for threadvars, or whether the target platform should provide more efficient support for them in its design and its libraries (here MS Windows API, Posix threads, etc.). The OS/2 target does not need any API call for accessing threadvars (thanks to the OS/2 design using "virtualization" features provided by the Intel architecture) and there is no compiler magic involved. Admittedly, this may not scale well to all types of CPU architectures (i.e. function call to a platform API may be more appropriate in the end to allow simpler and more powerful CPU architectures alike), but there is no need why the platform API should be more complicated (i.e. slower) than the simple pointer access (as used with the OS/2 implementation for threadvar access) on a CPU architecture providing such features.

Tomas

On Mon, Mar 4, 2013 at 10:25 AM, Kostas Michalopoulos <

Nice link, but I find this more appropriate:
http://lmgtfy.com/?q=how+to+benchmark+compilers
Related, abeit exploited http://tvtropes.org/pmwiki/pmwiki.php/Main/Troll

Tomas Hajny wrote

It's questionable whether it should be responsibility of a compiler to provide efficient support for threadvars,

If the target platform does not support threadvars a compiler can't do the target platform only provides library calls, a compiler needs to use them.

If the target platform provides dedicated pointer registers for threadvars a compiler can use them.

In all fpc enabled patforms I examined (X86 Windows, X86 Linux, X64-64 Windows, X86-64 Linux, ARM Linux (32 Bits) the platform provides as well library calls as dedicated threadvar pointer registers. In windows the registers seem to be undocumented but obviously "stable", as a change would break a lot existing C/C++ software.

All C/C++ compilers I examined used the threadvar pointer Registers for speed..

-Michael

Did you see the "..."?
I do not consider defects too...

Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;)

I agree.

Marcos Douglas

Is this correct? It implies that every feature/property uses 100% of the total process. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-)

Martin

Or it means you have 50 combinable features, so 2^50 >= 1 quadrillion possibilities. ;)

Mattias

These two should not result in much slowdowns if not used. Especially for helpers I've taken care of it. Though I admit that there is room for improvement for generics (but I already have ideas for that :) )

Regards,
Sven

Op Mon, 4 Mar 2013, schreef Martin Schreiber:

Some features only request procesing power if you use them. However, the features in Florian's list require continuous processing power. Two examples how features can impact overall speed:

1. Operator overloading

Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node.

With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded.

For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used.

The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions.

So even if you don't use operator overloading or variants at all, they do affect the compiler speed.

2. Layered code generation

The split of the code generation in a high-level and low-level layer, means that for every node that is processed, first the high-level virtual method is called, which in turn calls the lower level virtual method. Thus you have an addition virtual method call for evey node processed.

The low level code generator, which is still mostly CPU independent, again calls virtual methods from the abstract assembler layer to generate the actual opcodes.

The abstract assembler in turn, has again to worry about multiple assemblers which can emit the final object file.

Now each layer not just has its own code, but also its own type and therefore conversion functions need to be called (for example a def has a size), which is converted into a cgsize and ultimately into an opsize.

Obviously, if you just had one layer, and could output instruction directly to the object file, you can save a lot of performance.

While you might develop for just one platform, the fact that many of them are supported, costs compiler performance.

Daniël

Maybe we can improve this situation. For class helpers I added the possibility to add flags to symtables (so that only units are checked that really contain class helpers). Maybe we can add an additional "has_operators" flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the symtable of e.g. advanced records up to the unit symtable when parsing the record's declaration). As most units don't declare operators this could result in a little speedup especially considering that the lookup is done on each operator... and then we might add some caching structures to improve this further.

Regards,
Sven

That seems simple enough to implement and test ?

Michael.

Is there no cache?
Something like: Give me all '+' operator overloads in all used units of interface, implementation.

Can this be cached?
Maybe the compiler can reuse some results?

So even if you don't use operator overloading or variants at all, they do affect the compiler speed.

Mattias

In our previous episode, Mattias Gaertner said:

You need the implementation highest in the scope stack. "all" doesn't help, and they can also be implemented in the unit (or even local?) scope.

One would need to build the cache lazily (on first access in a scope), and somehow avoid rebuilding too often if the scope changes.

No I think not. The context to be checked is probably too large/complex.

Op Mon, 4 Mar 2013, schreef Mattias Gaertner:

Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation.

Actually a cache was part of my symtable redesign years ago. It never made it into the compiler. But it was designed with a slightly different idea in mind: If you do a symtable lookup you can have many symtables to process:

- With statement
- Local variables
- Parameters
- Object symtables, one per inherited object
- Unit symtables, two per loaded unit (interface & implementation)

The idea was to remove this lineair search through all symtables.

The concept never made it in the final compiler.

Daniël

Yes, maybe I'll give it a try in the next couple days (if no one beats me :) ).

Regards,
Sven

Did you work out the concept somewhere?

Regards,
Sven

Op Mon, 4 Mar 2013, schreef Mattias Gaertner:

Can this be cached? Maybe the compiler can reuse some results?

No. The symtable lookups can be parsed, but the candidate selection, which I believe is actually more compute intensive, is dependend on the actual situation where the operator is called, for example the types of the left and right part, which would not yield very high hit rates.

Originally the compiler was doing the candidate selection with a simple loop through the parameters that took the first suitable match. When the type conversion matters became more complex the "Unable to determine overloaded procedure" error became increasingle annoying.

At some point I did redesign it with scoring system: Each candidate that is compatible gets assigned a score how well the overloaded procedure matches the parameters. The best match is selected.

At that point, the compiler became highly intelligent in finding the correct overloaded procedure/operator, but the amount of computing power involved with overloading went up: Instead of selecting the first candidate, we need to compute the score for all candidates. This even requires floating point arithmetic.

Daniël

Op Mon, 4 Mar 2013, schreef Sven Barth:

Did you work out the concept somewhere?

It quite likely there is some archived copy of it in the old CVS repository, but I am sure it's better to start from scratch. The compiler was still using objects at that time, for example.

Daniël

Yes, the compiler has to search first local and inherited scopes, which need all kind of special rules, so caching might not help here. But after searching the special scopes the compiler has to search the interface sections of all used units. And these results should be the same for the whole implementation section. So it sounds like a good candidate for caching.

One would need to build the cache lazily (on first access in a scope), and somehow avoid rebuilding too often if the scope changes.

Yes. Or make the cache not too specific. For example just cache the list of all operator overloads. The compiler still has to check each operator, but it does not have to search all symtables to gather all operators.
Or it can cache what operator does not have any overloads at all and can simply use the default.

Mattias

Thanks for sharing some good news as well :-)

Michael.

Ok... But can you elaborate a bit how you had planned the caching?

Regards,
Sven

In our previous episode, Martin Schreiber said:

Speculation on the reasons:
macosall is mostly a header (declarations), while the other programs probably have a higher code % ?

Why not?
I guess that a high percentage are only a few type,operator,type combinations.

Yes, it really helped. Nice work.

I'm just wondering why these scores should be different for each operator in a unit.

Mattias

Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0:

FPC 2.6.2 Windows 3.2..3.5s
Delphi 7 Windows 4.0s
FPC 2.6.2 Linux 5.0s
Kylix 3 Linux 4.0s.

It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows.

Martin

What does the content of MacOSAll have to do with being mostly declarations? Martin just wrote that he used differently compiled MSEides to highlight the same unit (though I wonder why the FPC Linux variant is the slowest...)

Regards,
Sven

Can we have this statement printed out and signed by you, please :D

Regards,
Sven

Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved.

Mattias

This improvement is very visible. I had big problems to make MSEide Delphi compatible because Delphi many times reported "Unable to determine overloaded procedure" where FPC has no problems. I think this is worth a slow down of compile time. :-)

Martin

Op Mon, 4 Mar 2013, schreef Mattias Gaertner:

interface
function substring(x,y:unicodestring):cardinal;
function substring(x,y:ansistring):cardinal;
function substring(x,y:shortstring):cardinal;
implementation

{...}

var a:unicodestring;
     b,c:ansistring;;
begin
   a:='banana-split';
   b:='banana-split';
   c:='banana';
   writeln(substring('banana','banana-split'));
   writeln(substring(b,a));
   writeln(substring(a,a));
end.

... we would have 3 cache lookups, and 3 misses. Then we have end of scope, the symtablestack changes, and we therefore have to invalidate the cache. In this example, a cache would therefore slowdown instead of speed-up.

Daniël

Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux.

Another source of slow-down may be file search: Windows ignores case. Linux does not -> depending on what you do, you need to search 3 times more files.

Michael.

Is the "starting MSEide" (as mentioned above) bit included in the measured time? That would probably imply quite some OS calls, of course...

Tomas

MacOSAll.pas is 8-bit. On both systems MSEIDE has to convert it to UCS-2 (afair not UTF-16).
Do you mean MSEIDE uses the Widestring manager functions to compare tokens?

Another source of slow-down may be file search: Windows ignores case. Linux does not -> depending on what you do, you need to search 3 times more files.

Yes, but Windows is easily 10 times slower on file stat functions. I had to add several caches into Lazarus, because of this. Some functions were hardly measurable under Linux, but took a minute under Windows.
And this is completely irrelevant for loading a single file.

Mattias

In our previous episode, Sven Barth said:

Yes, I took it as those compilers compiling, not as compiled loading and highlighting.

In our previous episode, Michael Van Canneyt said:

Or more codegenerating related, PIC costs a register?

Yes, that's one of the reasons why I disabled the cache in codetools for procedure overloads.

But I was talking about operator overloads. AFAIK there far less operator overloads. And if a unit uses operator
overloads, then usually only a few, but many times. I guess many units do not use overloaded it possible to measure how much time the compiler spends on searching overloaded operators?

Mattias

Sven Barth wrote

that really contain class helpers). Maybe we can add an additional "has_operators" flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the

See, so Martin posting performance results after every FPC release does pay off. Without his post, your proposal would probably not have happened. ;-)

Regards,
- Graeme -

No idea.
I am simply proposing possible causes while waiting for my testsuites to finish :-)

The only way to actually know is to measure all various factors: Evidence-based acting...

Michael.

It seems that I only achived around 0.1 to 0.2 seconds when compiling the compiler (manually, with -B). But it's now checking only unit System and unit constexp (part of the compiler) for operator overloads.

It's also interesting to see that not every unit triggers a search for operators...

Regards,
Sven

And compiling with 2.6.0 is around 0.1 to 0.3 seconds faster.

And before I forget it: Platform is i386-win32.

Regards,
Sven

Op Mon, 4 Mar 2013, schreef Sven Barth:

So this is +/- 2%? Not bad. This fits perfectly into what Florian did explain: Each of the features adds just a bit of compile time. There is no quick solution to make FPC much faster. But each optimization can help a bit.

Daniël

Probably little but this is exactly my point: there are a dozens of such small slow downs. None of them really significant, overall they add up and most can be improved only with some bug and error prone hacks not worth the effort compared with other stuff on the todo lists.

You can see it the other way round: Sven might now spend a significant amount of time in a bug prone micro optimization of the compiler shaving off maybe 1% compilation time while he could do something else where a lot more users benefit like improving the register allocator or fixing unicode string issues.

Then I'll commit my changes :)

Regards,
Sven

It's a bit different: Sven spent a small amount of time with a working micro optimization of the compiler shaving of maybe 2% compilation time while he could have done boring work on a manual :P

And I'll leave unicode string issues to others while playing around with the register allocator sounds interesting. But before that I'd want to fix that annoying "compilation aborted" bug when recompiling the compiler without "-B"...

Regards,
Sven

2013/3/4 Martin Schreiber :

While the discussion is geared mostly towards compilation speed (it was already pointed why is slower than delphi and why cannot be improved easily improved), i'd like to point the produced code quality.

Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower?

If the generated code is not optimal yet, the devs already know the areas that can be improved?

Personally, i don't care much about compilation speed since is faster enough (at least for me). I'm more interested in better generated code. This is were i'd like to see the efforts going.

Luiz

Op Mon, 4 Mar 2013, schreef luiz americo pereira camara:

Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower?

There are again multiple reasons. One is indeed that the code is multiple-platform and therefore some abstraction exist in the RTL. For example, widestring and threat managers mean more code, but make things more flexible.

Further: FPC tries to implement every Delphi feature, but also has unique features. Some of these unique features require runtime overhead and thus cause a bigger RTL.

Assembler implementations can reduce the size of the RTL, but FPC tries to focus on portability and has therefore relatively less assembler in the RTL.

Code generation quality is another factor. While FPC has in absolute terms more optimization power than Delphi, it misses a few crucial optimizations. For example, we don't have loop induction, which allows Delphi to beat FPC in code that stresses this.

Further, especially regarding Lazarus, the design of the LCL simply means that a lot of code is pulled into the executable. The Delphi VCL offers more possibilities for smart linking away unneeded code.

Daniël

Sven Barth wrote

Then I'll commit my changes :)

Thanks for your efforts Sven.

Regards,
- Graeme -

Yes. The time is from pressing enter with "mseide" respective "mseidefp" on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the source editor window is colored. MSEide first shows the file without colors and does the highlighting in background if main event loop is idle.

Martin

2013/3/4 Daniël Mantione :

[..]

Thanks for the response. It clarified me.

Just a note. The Martin test, and my question in general, is not affected by LCL so the LCL size overhead is not relevant here

Luiz

What I'm trying to say is that gcc is going 3 times faster on my quad core machine because of the build system, not because they've turned their compiler into a multi-threaded clusterfsck. In my ignorance, I'm assuming that the same can't be achieved with pascal, then (without making the compiler itself multi-threaded)?

Henry

And how much time is spent on the highlighting on Linux and Windows?

Mattias

About 2/3 on booth. I need to instrument the code in order to get more precise numbers.

Martin

I don't know. I often find Windows 2000 faster than Linux.

Martin

I am not so sure about this.
===============================
Hmm - 20 (!) times (!!) difference. Usually it means design flaws thus broad ways for improvements & reworks.

Ivanko B wrote

I am not so sure about this. =============================== Hmm - 20 (!) times (!!) difference. Usually it means design flaws thus broad ways for improvements & reworks.

Awaiting your patches.

Did you actually read my complete mail? Some do, some do not, other might have a higher impact than only 10%.

And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-)

No, because Moore is still with us.

In our previous episode, Henry Vermaak said:

IMHO a threading clusterfsck is preferable to a forking clusterfck :-)

Yes. But is that incremental? It is fun to speed up a full build, but in reality developers are more likely to do a partial one. Ever pressed F9 after a small change in Delphi? The app starts nearly immediately, if the change wasn't too deep in the hierarchy of dependencies.

But compilation units in C have weaker(no) coherence than in (modular) Pascal, and C does not have an auto build system. All dependencies are done manually. (sometimes assisted with semi automated tools)

This means you need to manually specify in the build system which compilation unit depends on which headers. And this is also why in C/C++ inline functions are in the header, so that this model is persistent, since most builds are not full, but incremental.

To build (possibly incremental) an interweaved codebase means handling complete control to make, and essentially means castrating FPC to the gcc model of one process, one compilation unit (and killing all auto dependency tracking and no recompile unless updated).

This also means that for every codebase dependencies must be maintained. There might be semi-automated tools for it, but it is always a manual responsibility in the end. This is more or less done for the RTL. If it fails however, the result is partial builds, and errors pascal people are not used to.

Of course you can also try to identify isolated groups of uses that can be build in parallel, and try to build those, with autobuild within that group. This happens in the packages/ directory, where only the dependency graph of whole dirs is maintained.

assuming that the same can't be achieved with pascal, then (without making the compiler itself multi-threaded)?

Basically, there is a small piece of make in the compiler for incremental building, and determining what sources need to be compiled (just handing a mainmodule +dirs to the compiler will build it all).

This means the compiler can make decisions outside make's control, and also does extra checks (to find a consistent state for the code that abides the modular system before linking)

As shown above, you can work around that with makefile generators (packages/) or hard work (rtl/). But for dynamic codebases of closely knit units like IDEs and compilers there really is no solution atm.

If you have an option to force the compiler to only compile one unit, you could emulate the C model. You could even improve on the C situation by letting the compiler terminate on inconsistent incremental build state (to signal the dependencies are fscked)

But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire.

C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc.

Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told.

And FPC even only in a few critical points.

Manual maintenance is simply too painful (and atypical for modular languages and its users).

My gut feeling would be that the complexity and potential bugs/races don't make up for the speed, but maybe a threaded compiler gains a lot more than I imagine. Are there any multi-threaded compilers around for comparison?

As you probably know, you can use -MD and variants with gcc, which outputs dependency files for make, that you then include in the Makefile. If you add, e.g. -MMD to the CFLAGS, these dependencies are generated as a side effect of the compilation process, so it's not a separate step. As a result, partial builds work really well, and can be parallelized as usual. No manual work involved.

Henry

C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc.
---------------
Inflicting this on the Pascal masses is unrealistic and undesirable. ==============
100% !
C(++) building system is a nightmare. It hardly worths to take.

But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters.

Make can not figure out the dependencies between units by itself as it would need to parse them.

Regards,
Sven

That's for the user to do, if he thinks he can do a better job than FPC.

In theory you can do it already. Compile each unit with "-Ur" (release unit) and the compiler will not attempt to recompile such a unit and prefer to fail. And then you do a compilation run for each unit. Good luck though for circular dependencies (the legal ones).

Regards,
Sven

Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this.

Henry

As this is something we (as in the FPC developers) don't need: patches are welcome.

[or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ]

Regards,
Sven

Possibly augmented by timestamp-based validity checking. Yes, but I didn't want to muddy the water by suggesting too many things at once :-)

Seriously: if FPC's putting too much internal work into sorting out dependencies and somebody is prepared to write his code for an alternative build system, then give him enough rope. But it would obviously shine a harsh light on the compiler if this turned out not to be the major bottleneck.

There is a new tool "pas2fpm.pp" which can easily be adapted to do this. It already calculates the dependencies, but outputs them in fpmake form.

Michael.

I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then?

I'm not ordering anyone to implement features, I'm exploring solutions to the depressing fact that my c projects compile quicker than my fpc projects (simply because my build system can launch parallel jobs). I don't think that turning fpc into a multi-threaded compiler is a sane thing to do.

Henry

Michael Van Canneyt hat am 5. März 2013 um 11:09 geschrieben:

Is this correct:
You need the tool pas2fpm to feed the tool fpmake to feed the tool fpc to feed linker, lazres ....

Mattias

Michael Van Canneyt wrote

There is a new tool "pas2fpm.pp" which can easily be adapted to do this. It already calculates the dependencies, but outputs them in fpmake form.

Ah, I remember that fpmake can build with multiple threads, so perhaps this is a better solution than to do it with make. I'll investigate.

Henry

You don't need anything. You can create fpmake.pp yourself.

pas2fpm makes it easier for you.

Just like "configure" and "autoconf" make it easier to create Makefiles if you use C.

But because pas2fpm parses your units to do its job, it can go wrong, even on legal code. So using it should be optional.

You could try and integrate all in 1 tool (like in an IDE as lazarus). fpmake was set up so it can be integrated completely in lazarus if you want it. Same for fppkg.

Michael.

In our previous episode, Henry Vermaak said:

Not the normal free ones. But that is not really a metric, but none of them were designed for modular languages, stronger, they don't even use features like precompiled headers that commercial ones already have for a long time.

Note that strictly only the part of make *must* be multithreaded, the compilation of a compilation unit is basically the current single threaded compiler running in its own thread.

So the parts that decide which compilation unit must be loaded, and parts of the unit loader.

I think the problem is more doing it in a non-trivial production compiler, than the principle itself.

No, but I did know other tools for that yes. Compiler output is better of course.

If you add, e.g. -MMD to the CFLAGS, these dependencies are generated as a side effect of the compilation process, so it's not a separate step. As a result, partial builds work really well, and can be parallelized as usual. No manual work involved.

Maybe that works for FPC too. But FPC can currently compile units multiple times afaik. (to detangle circular references), FPC afaik also registers some preprocessor state, and compiles on change.

So basically make is meant for a different execution model IMHO, and it shouldn't be made a cornerstone. It is only a stopgap till we have something that fits with the unit system.

In our previous episode, Henry Vermaak said:

That does't work, since in FPC an unit is an interface AND an implementation. And inline functions are in the implementation, not the interface.

The only way is to simply toss the modular system (units) out, and work with $i, declare functions as externals in headers, let the compiler spit out dependencies.

Henry Vermaak wrote

Ah, I remember that fpmake can build with multiple threads, so perhaps this is a better solution than to do it with make. I'll investigate.

I've got that option enabled by default for building FPC 2.7.1 and it does shave off a few seconds.

I'm also trying to use fpmake for other "hourly build server" tasks, where I need to do clean compiles of various independent packages first, then build the test suite that pulls everything together. eg: building Synapse, FBLib, tiOPF, EpikTimer, fpGUI etc in parallel. Then somehow wait until they are all done, then build the test suite which uses all those packages. I still haven't figure this process out yet. If you have hints or suggestion on this, it would be greatly appreciated [maybe follow-up in a new message thread in fpc-pascal]

Regards,
- Graeme -

OK, I'll drop this line of enquiry then :) Thanks for the information (and the patience).

Henry

I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then?

Yes and no. It would mean to create kind of header files for the Pascal units, usable to compile the units independently. No problem at a first glance, the Interface is the equivalent of an C header file, and the Uses lists are equivalent to further #includes. One of the remaining problems are the lost unit qualifiers, so that external references in the object files cannot be safely resolved.

But in fact above is what FPC already does! When it encounters a Uses list, it loads the according PPU or, if not available or outdated, compiles the requested unit. Thus the PPU files already *are* the equivalent of the C header files. Plus the bonus that every "header" has to be loaded only once, not for every single module to be compiled by an C compiler.

The problem IMO is the long list of units waiting for their dependencies loaded, before the first unit can be compiled at all (top-down). More efficient were bottom-up compilation, starting with the units with only few dependencies, so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies.

DoDi

In our previous episode, Henry Vermaak said:

No problem at all, writing it down helped me see things more clearly too.

I before never thought about the incremental build aspect.

on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages... one is created when the section is entered into and another when the section is successfully compiled... it is mostly all C stuff and uses make... it is all pretty much FM to me as i only start it and wait for it to reach my modules and see if they compile or fail... if they fail, i (w)hack at them some more... the breadcrumbs allow the compilation environment to pick up where it left off instead of spending two hours recompiling everything again up to the point of failure...

maybe this can give you some ideas?

FWIW: the above breadcrumb system that i speak of is in the development version of an open source firewall product that i work with ;)

so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies.
==============
Disk I/O is a huge low-down to avoid on any price (like databases do with their indexing). Today me tested building LINUX kernel 3.8.0 on 8*SMT=16 CPU system (Corei7 2G) + 32G DDR3 + 175(wr)/350(rd)MB/s RAID1. And this monster outperformed another cheap E8400 + 4G machine by only 2 times and most probably because the cheap machine was non-RAIDed. And because Core i* arch can't have proper DMA.

"make -j 16 deb-pkg" vs "make -j 2 deb-pkg", sure :)

I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved.

make -j has a dramatic effect on an SMP system, particularly if it can find groups of jobs without too much interdependence. If there's a lot of shared input files etc., then my experience is that it tends to level out at around -j 8 since it's extremely difficult to improve the cache architecture beyond that point.

Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd:

Well... I put that into question. I don't have a 256 core system, but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a bit of compute power. Compiling kernel 3.3.2:

linux-3.3.2]# time make -j 64

...

real 1m54.823s
user 77m14.178s
sys 11m32.109s

To minutes to build a kernel is still fast though :)

Daniël

waldo kitty wrote

on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages...

Thanks for you input. It sounds similar to what I was planning. Simply create an empty file in /tmp when each independent package is compiled successfully. Another process keeps checking /tmp for all the 0 byte files in expects. If they all exist, then build the test suite. Once that is complete, remove all the 0 byte files, and run the test suite.

Now the question is, how good is fpmake? Will it can do something like that, or must I build my own system using scripts or console apps etc.

Regards,
- Graeme -

I didn't yet experiment that much with fpmake, but considering that fpmake.pas files are just plain Pascal programs...

Regards,
Sven

Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config?

Henry

Note that the release compilers are compiled with WPO and those optimizations change most of those virtual calls into static calls. Not all of them, but e.g. the entire code generator (both high and low level) does get devirtualized for most platforms (except for ARM, because it contains multiple low level code generators).

Jonas

Noting that for this test to be valid you obviously have to start from e.g. make clean and might usefully consider a reboot to make sure that all caches are empty.

My point however was that a kernel build parallelises to very good effect, even where each processor is "implausibly slow" by today's standards.

Op Tue, 5 Mar 2013, schreef Henry Vermaak:

Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config?

What is the standard config? As the operating system is Scientific Linux 6, I'm using the config for the standard 2.6.32 kernel with as little modifications as possible to use it for 3.3.2.

I don't have a 4 core Xeon system, but I tried to simulate it on a dual Xeon 2670 system by only using 4 cores:

src]# time numactl --physcpubind=0-3 make -j 4

...

real 11m45.748s
user 38m30.405s
sys 4m48.634s

Daniël

FWIW:
I rechecked this and can add these results:

With ARM, the pre-Cortex Arch on Linux uses A9 as a pointer to the TLS (Thread local Storage http://en.wikipedia.org/wiki/Thread-local_storage , that holds the threadvars). So (as with all x86 variants) no library or system call is necessary.

With Cortex, this has changed to the use of the CP15 Register (freeing A9 to allow for better optimization). Now, CP15 is in fact not very suitable for this purpose, as it can only be accessed with privileged instructions and thus not in user mode (where the TLS in fact is invented for). Thus a system call (or trap) is needed to get the address of a threadvar. As a system call supposedly is rather costly on ARM (invalidating the cache, as here, (other than with x86) the cache is closer to the CPU than the MMU) using a library call will not do additional harm.

Generally:

The frequent access to threadvars is necessary with threaded programs that use the same code in multiple threads to allow for each thread to find easily out "who I am" even in a deeply nested function environment.

But in an object driven language, this can easily be overcome by creating an instance of an object for each thread and with that, you always have the "Self" pointer as a thread specific entity. Happily "Self" resides on the stack that is dedicated for each thread, anyway, and is created automatically for any "procedure or object". So the use of any threadvar is necessary only when creating the thread-related object but it's not necessary to access any threadvar frequently.

Conclusion:

With FPC, the optimization of threadvar access is not necessary. Instead it is highly recommended to always use thread specific instances of the classes that do the threaded work. TThread of course provides this out of the box.

-Michael

Michael Schnell wrote

So (as with all x86 variants) no library or system call is necessary.

Wrong. This is not true in the general case, please read the appropriate api documents.

Wrong. On linux this can be done by a jump to a certain adress.

And how does one the "current" TThread?

I do know that on Windows it's documented like this by Microsoft. But I also know that the Microsoft C compiler (and AFAIK, gnu as well) does not adhere to that documentation but simply uses the appropriate selector register that the Intel chip designers happily provided for such kind of purpose. (We already discussed this here some years ago.)

Wrong. On linux this can be done by a jump to a certain adress.

OK. I did not thoroughly enough check into this. Does the jump to the system region automatically provide the mode switch without changing anything in the MMU (and this without the necessity to invalid the cache) ?

If yes a glibc library call might provide a noticeable overhead and it might be advantageous to do the system call directly in the RTL.

And how does one the "current" TThread?

Do you mean something like this:

Type
TMyThread = class(TThread)
  private
   currentthread: Integer;
end.
var
   threads: array[1..100] of TMyThread;
for i := 1 to 100 do begin
   thread[i] := TMyThread.Create;
   thread[i].currentthread := i;
end;
TMyThread.Execute;
var
   s: String;
begin
   s := 'I am ' + InToString(currentthread);
end;

?
-Michael

Sorry, meant something like standard distro config, i.e. not localmodconfig or customised.

3.8.2 with standard debian config on 4 core xeon:

real 28m19.009s
user 84m16.092s
sys 7m18.327s

Since a few weeks: TThread.CurrentThread ;)

Regards,
Sven

Martin Schreiber wrote

On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3

A last one, simple MSEgui demo, one form, a fancy tlabel, one button: http://mseide-msegui.sourceforge.net/pics/kylix3.png

Program size Kylix 3:
-rwxr-xr-x 1 mse users 1038420 Mar 6 13:28 kylixdemo

FPC 2.6.2, commandline:
ppc386 -okylixdemo -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2 -CX -XX -Xs kylixdemo.pas
Program size:
-rwxr-xr-x 1 mse users 1252204 Mar 6 14:10 kylixdemo

Martin

Sven Barth wrote

> And how does one the "current" TThread? Since a few weeks: TThread.CurrentThread ;)

This does in fact use a threadvar:

threadvar
{ the instance of the current thread; in case of an external thread this is
Nil until TThread.GetCurrentThread was called once (the RTLs need to ensure
that threadvars are initialized with 0!) }

   CurrentThreadVar: TThread;

and (unless the compiler optimizes this out) even accesses it twice:

   if not Assigned(CurrentThreadVar) then
     CurrentThreadVar := TExternalThread.Create;
   Result := CurrentThreadVar;

From within the TThread object, simply using Self seems more appropriate unless there is a chance that the same TThread instance is used for multiple OS-Threads. I don't know if/how this is possible.

From "outside" I feel that AnyThread.GetCurrentThread does not make much senses.

When doing "TThread.GetCurrentThread" as a class function I think I should get "self" of same when I am in the code that is called from "Execute" of some TThread instance. I don't see what I want to see when I'm not.

The code seems to try to avoid the case that a no TThread instance when GetCurrentThread is called as a a class function. I don't know if/how this is sensible.

Using CurrentThread only seems sensible within the the code of a component that has been called by the code of a TThread instance. But here using an appropriate back-link property can easily be used to avoid accessing the threadvar. (or using CurrentThread once to set a property and then just accessing same.) But this of course needs to be done in user code and the RTL can't force it.

-Michael

The TThread.CurrentThread is mainly for access in functions that don't get passed a "TThread" instance and to also get a "TThread" instance for threads not created by the RTL (the "TExternalThread.Create" line above). Don't forget that TThread.CurrentThread is a class property/function, so you can't access Self.

We could optimize it like this:

=== code begin ===

Result := CurrentThreadVar;
if not Assigned(Result) then begin
   Result := TExternalThread.Create;
   CurrentThreadVar := Result;
end;

=== code end ===

So that in the normal case only one access to the threadvar is used.

Regards,
Sven

make -j has a dramatic effect on an SMP system, particularly if it can find groups of jobs without too much interdependence. =================================
The benchamark was surprising. Diring it, me observed 80..95% load of each CPU still having high I/O load on the RAID1. How can it be ?! Which were the CPUs engaged for ?
Me guess because of the design flaw of Core-I* arch where proper (disk/network- to-from-RAM leaving CPUs idle from I/O) DMA transfers are impossible since the RAM can only be accessed via CPUs so CPUs has to serve each smallest I/O operation. Really very strange. The kernel is customized, sure :)

time make -j 64
======================
It might not build modules - which present a lot of files thsu I/O. "make -j .. deb-pkg" builds & packs both image & modules (the benchmark has selected for build approx 75% of all available modules )

I've implemented this optimization in r23706. So in the normal case the threadvar is only read once and in the worst case it's read once and written once.

Regards,
Sven

Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work.

Netiquette?

G.

This should have been shortened indeed...

To my defense: I wanted to get this mail out, fix another problem (see fpc-pascal list) and hop into bed...
You should also take into consideration that I normally *do* shorten my mails.

Regards,
Sven

2013/3/8 Graeme Geldenhuys :

Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work.

Good quoting, it just read that message and got a comprehensive story, especially because my autofilter deletes mails from Michael Schnelll.

Netiquette?

Spoilt by gmail.

Vincent

On 04/mar/2013, at 15:02, Michael Van Canneyt
wrote:

On Mon, 4 Mar 2013, Mattias Gaertner wrote:

On Mon, 4 Mar 2013 14:50:17 +0100

Martin Schreiber wrote:

Any idea, why FPC Linux is slower than FPC Windows?

Loading and highlighting does not sound like a task where many OS calls

are involved.

Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux.

Slightly off topic: http://www.utf8everywhere.org/ Seriously, drop UTF16 support NOW.

Vittorio

Sorry for the +1 style mail but I just wanted to say that completely agree with your statement!
Compilation speed is nice, but better code (size/speed) is... better! Vittorio

Vittorio Giovara wrote

Slightly off topic: http://www.utf8everywhere.org/ Seriously, drop UTF16 support NOW.

No, that's very off-topic. Please don't start discussions like that here, they don't lead to any useful outcome.

Jonas
FPC mailing lists admin

as a bonus, when the code that is output performs faster, so will the compiler itself after the recursive build. or one would think so :-)

kind regards,
Dimitri Smits

Without the used sources it is of very little use.

Because of the tone of the answers in this list I didn't expect anyone is interested in it. ;-)
http://gitorious.org/mseuniverse/mseuniverse/trees/master/testcase/kylix/kylixdemo

Martin