Re: [fpc-devel] Forwarded message about FPC status
Michael Van Canneyt wrote: On Mon, 24 Dec 2012, Martin Schreiber wrote: - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. You know that sacrifices need to be made to make a compiler cross platform and easily portable. You can't have it all. We will see. It would be good if, prior to forking off, you would do some study and post some proposals here. As long as your proposals do not include reducing the number of platforms/CPUs (an obvious optimization), I'm sure they will get serious consideration: Although I think the time is approaching when some CPUs- IA-64 etc.- and OSes could usefully be moved into an attic subtree. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
From what I remember, the problems you (and everyone else) experience
with smartlinking and so on are largely due to the GNU linker being
slow and memory hungry.
AFAIK there are significant differences in parsing and code producing too.
Last time I checked on Windows with the internal FPC linker Delphi 7 compiled
and linked about 10 times as fast as FPC.
What concerns produced code: I think that the largest speed gain there
will come from a reorganisation of the exception handling.
What concerns 'stripping the unnecessary' : if you are talking
about language features, I doubt you will gain much speed by that.
The goal here is to reduce the count of the used different concepts so one has
not to learn much to tap the full potential of the language.
I am also fairly confident that if you would create a patch to
introduce a new compiler mode switch {$MODE D7} which would
selectively enable/disable some language features to go back
to the roots, it would be accepted. (I myself would use it ;))
It would unfortunately blow up the code base again.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Tue, 25 Dec 2012, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
From what I remember, the problems you (and everyone else) experience
with smartlinking and so on are largely due to the GNU linker being
slow and memory hungry.
AFAIK there are significant differences in parsing and code producing too.
I suggest that Florian answers this, he has more exact numbers.
Last time I checked on Windows with the internal FPC linker Delphi 7 compiled
and linked about 10 times as fast as FPC.
AFAIK it is still linker related: the assembler files are on disk,
the structure of the files is geared towards the GNU toolchain etc.
What concerns produced code: I think that the largest speed gain there
will come from a reorganisation of the exception handling.
What concerns 'stripping the unnecessary' : if you are talking
about language features, I doubt you will gain much speed by that.
The goal here is to reduce the count of the used different concepts so one has
not to learn much to tap the full potential of the language.
This is a goal I fully support.
And I consider it a perfect fit for a mode switch.
I am also fairly confident that if you would create a patch to
introduce a new compiler mode switch {$MODE D7} which would
selectively enable/disable some language features to go back
to the roots, it would be accepted. (I myself would use it ;))
It would unfortunately blow up the code base again.
By about 10 lines in the compiler, so this is hardly an argument.
And - assuming you don't insist on forking - there will be more
people to manage these 10 lines.
As we've explained elsewhere, not breaking things is always an
important thing, so no-one would take this switch away.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Tue, 25 Dec 2012, Sven Barth wrote: On 25.12.2012 12:13, Martin Schreiber wrote: On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote: Everybody is aware of the speed difference between Delphi and FPC. The compiling itself (parsing/producing assembler code) is not slow. From what I remember, the problems you (and everyone else) experience with smartlinking and so on are largely due to the GNU linker being slow and memory hungry. AFAIK there are significant differences in parsing and code producing too. Last time I checked on Windows with the internal FPC linker Delphi 7 compiled and linked about 10 times as fast as FPC. AFAIK Delphi's command line compiler does not allow you to skip the assembling and linking phase, so the fairest comparison would be to compare the compilation of a single unit as there the linking phase is skipped. If Delphi is still better there then there are two possibilities: improve the internal assembler or the parser/code generator. Please keep in mind though that FPC's code generator is written in such a way that the backend can be switched rather easily. As we learned with the developer's blog entries about Delphi XE2 this wasn't the case with Delphi XE and older. So it could be that you can never reach the speed of Delphi 7's compiler as FPC is more portable. Which is why I wrote that limiting the number of CPUs/Platforms would be the obvious optimisation, but one which is incompatible with FPC's goals. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
In our previous episode, Sven Barth said: and linked about 10 times as fast as FPC. AFAIK Delphi's command line compiler does not allow you to skip the assembling and linking phase, so the fairest comparison would be to compare the compilation of a single unit as there the linking phase is skipped. If Delphi is still better there then there are two possibilities: improve the internal assembler or the parser/code generator. Please keep in mind though that FPC's code generator is written in such a way that the backend can be switched rather easily. As we learned with the developer's blog entries about Delphi XE2 this wasn't the case with Delphi XE and older. So it could be that you can never reach the speed of Delphi 7's compiler as FPC is more portable. The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. I had a setup where I compiled zeos with FPC and Delphi (which doesn't link), and iirc the results were also 7-10times, with delphi XE. When I'm home after Christmas I'll play a bit and see if I can duplicate the experiments with Delphi XE3. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 25.12.2012 12:40, Michael Van Canneyt wrote: On Tue, 25 Dec 2012, Sven Barth wrote: On 25.12.2012 12:13, Martin Schreiber wrote: On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote: Everybody is aware of the speed difference between Delphi and FPC. The compiling itself (parsing/producing assembler code) is not slow. From what I remember, the problems you (and everyone else) experience with smartlinking and so on are largely due to the GNU linker being slow and memory hungry. AFAIK there are significant differences in parsing and code producing too. Last time I checked on Windows with the internal FPC linker Delphi 7 compiled and linked about 10 times as fast as FPC. AFAIK Delphi's command line compiler does not allow you to skip the assembling and linking phase, so the fairest comparison would be to compare the compilation of a single unit as there the linking phase is skipped. If Delphi is still better there then there are two possibilities: improve the internal assembler or the parser/code generator. Please keep in mind though that FPC's code generator is written in such a way that the backend can be switched rather easily. As we learned with the developer's blog entries about Delphi XE2 this wasn't the case with Delphi XE and older. So it could be that you can never reach the speed of Delphi 7's compiler as FPC is more portable. Which is why I wrote that limiting the number of CPUs/Platforms would be the obvious optimisation, but one which is incompatible with FPC's goals. It would not only be limiting the amount amount of CPUs/Platforms. As long as at least two CPUs exist that use the compiler's current backend system it can't be optimized (at least not in that sense). You'd need to basically bring the code generator back to a pre-1.9 state to gain significant performance with reducing the number of target CPUs. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Sven Barth wrote: On 25.12.2012 11:32, Mark Morgan Lloyd wrote: Although I think the time is approaching when some CPUs- IA-64 etc.- and OSes could usefully be moved into an attic subtree. They aren't compiled anyway, so they don't affect the compiler's performance negatively. So it does not matter whether they are inside the compiler tree or something else. And after all there could somebody who takes enough interest to implement such a CPU... *cough* m68k *cough* ;) Agreed. But combinations that don't compile meaningfully (e.g. the compiler targeting IA-64) or at all without at least backported patches (various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be in compiler/attic and rtl/attic. In other words, anything in the main directories should compile and run, and if somebody spots that that is no longer the case then it's a candidate for being fixed. Obviously this is a personal opinion. I for one am not trying to hector, badger, buffalo or otherwise irritate the coee team :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Marco van de Voort mar...@stack.nl In our previous episode, Sven Barth said: and linked about 10 times as fast as FPC. AFAIK Delphi's command line compiler does not allow you to skip the assembling and linking phase, so the fairest comparison would be to compare the compilation of a single unit as there the linking phase is skipped. If Delphi is still better there then there are two possibilities: improve the internal assembler or the parser/code generator. Please keep in mind though that FPC's code generator is written in such a way that the backend can be switched rather easily. As we learned with the developer's blog entries about Delphi XE2 this wasn't the case with Delphi XE and older. So it could be that you can never reach the speed of Delphi 7's compiler as FPC is more portable. The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. I had a setup where I compiled zeos with FPC and Delphi (which doesn't link), and iirc the results were also 7-10times, with delphi XE. I also got similar results few years ago. Also I made some profiling and found a bottleneck in FPC. It is HUGE number of creations of small (or even tiny) objects (various compiler nodes). Each object creation allocates small chunk of memory and zero fills it. It is very time consuming. It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Although I think the time is approaching when some CPUs- IA-64 etc.- and OSes could usefully be moved into an attic subtree. Agreed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 25.12.2012 12:38, schrieb Michael Van Canneyt: On Tue, 25 Dec 2012, Martin Schreiber wrote: On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote: Everybody is aware of the speed difference between Delphi and FPC. The compiling itself (parsing/producing assembler code) is not slow. From what I remember, the problems you (and everyone else) experience with smartlinking and so on are largely due to the GNU linker being slow and memory hungry. AFAIK there are significant differences in parsing and code producing too. I suggest that Florian answers this, he has more exact numbers. I see no way to speed up the 2.x FPC significantly only by stripping something down or whatever. The whole 2.x design is geared towards portability and maintainability, speed is only 2nd level goal (and being honest, self compilation in ~10 sec even on my 5 year old Core 2 Duo is not that bad ;)). The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 25.12.2012 13:24, Mark Morgan Lloyd wrote: Sven Barth wrote: On 25.12.2012 11:32, Mark Morgan Lloyd wrote: Although I think the time is approaching when some CPUs- IA-64 etc.- and OSes could usefully be moved into an attic subtree. They aren't compiled anyway, so they don't affect the compiler's performance negatively. So it does not matter whether they are inside the compiler tree or something else. And after all there could somebody who takes enough interest to implement such a CPU... *cough* m68k *cough* ;) Agreed. But combinations that don't compile meaningfully (e.g. the compiler targeting IA-64) or at all without at least backported patches (various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be in compiler/attic and rtl/attic. In other words, anything in the main directories should compile and run, and if somebody spots that that is no longer the case then it's a candidate for being fixed. You can cross Amiga from that list. At least the PowerPC RTL compiled all time long and recently the m68k RTL was fixed and a 'hello world' app worked. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Florian Klaempfl flor...@freepascal.org Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... Still zero-filling a million of small memory chunks is very time consuming. It is better to pre-zerofill big pool blocks first and then assueme that memory already zero fillled in custom object init code. Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. Is this close i386 intermediate code similar to IR LLVM generation ? if so, this may become a good option for a new strategy ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Yury Sidorov j...@cp-lab.com From: Florian Klaempfl flor...@freepascal.org Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... Still zero-filling a million of small memory chunks is very time consuming. It is better to pre-zerofill big pool blocks first and then assueme that memory already zero fillled in custom object init code. Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 14:53, schrieb Jy V: Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. I do agree, you should consider his position. The total time FPC spend in memory manangement is 20% iirc. So I don't see much optimization potential here. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
The total time FPC spend in memory manangement is 20% iirc. So I don't see much optimization potential here. OK. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 25.12.2012 14:44, schrieb Jy V: The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. Is this close i386 intermediate code similar to IR LLVM generation ? No. It must be much closer to i386 else there is no speed advantage over the current approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Is this close i386 intermediate code similar to IR LLVM generation ? No. It must be much closer to i386 else there is no speed advantage over the current approach. OK, understood. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 25.12.2012 14:15, Florian Klaempfl wrote: The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. Ewww... please not... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 25.12.2012 15:04, schrieb Sven Barth: On 25.12.2012 14:15, Florian Klaempfl wrote: The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. Ewww... please not... No, we would be back in pre 1.0 times :) Not to mention the fact that writing such a backend probably takes one year of work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 14:59, schrieb Yury Sidorov: From: Yury Sidorov j...@cp-lab.com From: Florian Klaempfl flor...@freepascal.org Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... Still zero-filling a million of small memory chunks is very time consuming. It is better to pre-zerofill big pool blocks first and then assueme that memory already zero fillled in custom object init code. Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( Ops, messages crossed :) I'd expect no more. One thing might be to rewrite the whole unit handling so that symtables etc. can be read/written as one block to PPUs but doing so might be also pretty time consuming and I doubt the maintainability of such an approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 15:11, schrieb Paul Ishenin: 25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Yes, but you might also pay with a higher memory footprint which might even eat this speed advantage under certain circumstances. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Paul Ishenin paul.ishe...@gmail.com 25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Sure, but I would be happy to expect at least 2X increase :) In such case I would start coding the fix right now :) Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 15:17, schrieb Yury Sidorov: From: Paul Ishenin paul.ishe...@gmail.com 25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Sure, but I would be happy to expect at least 2X increase :) In such case I would start coding the fix right now :) Believe me, if it was so easy, I would have it done for years ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? This would allow to keep the many features of fpc. I had a setup where I compiled zeos with FPC and Delphi (which doesn't link), and iirc the results were also 7-10times, with delphi XE. When I'm home after Christmas I'll play a bit and see if I can duplicate the experiments with Delphi XE3. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. This would allow to keep the many features of fpc. I had a setup where I compiled zeos with FPC and Delphi (which doesn't link), and iirc the results were also 7-10times, with delphi XE. When I'm home after Christmas I'll play a bit and see if I can duplicate the experiments with Delphi XE3. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Florian Klaempfl wrote: Am 25.12.2012 15:11, schrieb Paul Ishenin: 25.12.12, 21:59, Yury Sidorov ?: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Yes, but you might also pay with a higher memory footprint which might even eat this speed advantage under certain circumstances. If the memory footprint was less than was needed for the linkage stage would this matter? Obviously this isn't comparing like with like, since the compiler footprint would presumably be per-unit rather than for the entire program. But any realistic development system has to be prepared to allocate enough memory for linkage, 512Mb is realistic for building e.g. Lazarus so it's reasonable to argue that that space is also available for compilation. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Sven Barth wrote: On 25.12.2012 13:24, Mark Morgan Lloyd wrote: Agreed. But combinations that don't compile meaningfully (e.g. the compiler targeting IA-64) or at all without at least backported patches (various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be in compiler/attic and rtl/attic. In other words, anything in the main directories should compile and run, and if somebody spots that that is no longer the case then it's a candidate for being fixed. You can cross Amiga from that list. At least the PowerPC RTL compiled all time long and recently the m68k RTL was fixed and a 'hello world' app worked. Presumably over the last week or so. When I was looking at Max OS (classic) a few days ago I was usefully comparing the difference between the Amiga and Morphos RTL. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
In our previous episode, Mark Morgan Lloyd said: interest to implement such a CPU... *cough* m68k *cough* ;) Agreed. But combinations that don't compile meaningfully (e.g. the compiler targeting IA-64) or at all without at least backported patches (various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be in compiler/attic and rtl/attic. In other words, anything in the main directories should compile and run, and if somebody spots that that is no longer the case then it's a candidate for being fixed. Obviously this is a personal opinion. I for one am not trying to hector, badger, buffalo or otherwise irritate the coee team :-) Doesn't that only inflate SVN backup sizes? Better have some textfile (in SVN for that matter) that explains a bit more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
- Oorspronkelijk e-mail - Van: Florian Klaempfl flor...@freepascal.org Aan: FPC developers' list fpc-devel@lists.freepascal.org Verzonden: Dinsdag 25 december 2012 14:15:24 Onderwerp: Re: [fpc-devel] Forwarded message about FPC status I see no way to speed up the 2.x FPC significantly only by stripping something down or whatever. The whole 2.x design is geared towards portability and maintainability, speed is only 2nd level goal (and being honest, self compilation in ~10 sec even on my 5 year old Core 2 Duo is not that bad ;)). I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the compiler on windows was at least a few minutes. what I *think* is a large hog on compilation/linking is the spawning of multiple executables in the different steps as opposed to the monolithic exe(+dll) that dcc32.exe is. The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. lovely, but isn't that what Embarcadero is doing for their future compiler? Using the llvm toolchain, they will provide a front compiler to an intermediate language or interpreted code. Then they have a few optimisations for the middle layer and use the back-ends that are already available to make stuff architecturally compile to whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or custom backend) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
On Tue, 25 Dec 2012 18:01:50 +0100 Florian Klaempfl flor...@freepascal.org wrote: Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. Do you mean as separate process? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 25.12.2012 18:12, Mark Morgan Lloyd wrote: Sven Barth wrote: On 25.12.2012 13:24, Mark Morgan Lloyd wrote: Agreed. But combinations that don't compile meaningfully (e.g. the compiler targeting IA-64) or at all without at least backported patches (various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be in compiler/attic and rtl/attic. In other words, anything in the main directories should compile and run, and if somebody spots that that is no longer the case then it's a candidate for being fixed. You can cross Amiga from that list. At least the PowerPC RTL compiled all time long and recently the m68k RTL was fixed and a 'hello world' app worked. Presumably over the last week or so. When I was looking at Max OS (classic) a few days ago I was usefully comparing the difference between the Amiga and Morphos RTL. Yes, it was at the beginning of last week from the one developer who had also implemented the Morphos RTL (you can take a look at the SVN log if you want). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
On 25.12.2012 18:10, Mark Morgan Lloyd wrote: Florian Klaempfl wrote: Am 25.12.2012 15:11, schrieb Paul Ishenin: 25.12.12, 21:59, Yury Sidorov ?: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Yes, but you might also pay with a higher memory footprint which might even eat this speed advantage under certain circumstances. If the memory footprint was less than was needed for the linkage stage would this matter? Obviously this isn't comparing like with like, since the compiler footprint would presumably be per-unit rather than for the entire program. But any realistic development system has to be prepared to allocate enough memory for linkage, 512Mb is realistic for building e.g. Lazarus so it's reasonable to argue that that space is also available for compilation. If you compile a project from scratch (let's keep aside the RTL, FCL and LCL) then the compiler will keep more data in memory than when the project is recompiled and e.g. no of the dependant units were changed. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 25.12.2012 19:30, schrieb Dimitri Smits: I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the compiler on windows was at least a few minutes. It is windows: self compilation. No rtl building or whatever. The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. lovely, but isn't that what Embarcadero is doing for their future compiler? No. It is exactly the counterpart. llvm intermediate language is for sure as much as possible platform independent and not close to i386 as I wrote. If one wants to accelarate FPC by one magnitude one cannot fiddle with some abstract intermediate layer but output already from the parser something as close as possible to i386 machine code, do register allocations and optimizations on it and write the machine code to disk. Using the llvm toolchain, they will provide a front compiler to an intermediate language or interpreted code. Then they have a few optimisations for the middle layer and use the back-ends that are already available to make stuff architecturally compile to whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or custom backend) ... and this costs time. And it is similiar to FPC's approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 19:39, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 18:01:50 +0100 Florian Klaempfl flor...@freepascal.org wrote: Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. Do you mean as separate process? Yes. ppcxyz would be only a front end to this daemon process/service. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 25.12.2012 19:30, Dimitri Smits wrote: - Oorspronkelijk e-mail - Van: Florian Klaempfl flor...@freepascal.org Aan: FPC developers' list fpc-devel@lists.freepascal.org Verzonden: Dinsdag 25 december 2012 14:15:24 Onderwerp: Re: [fpc-devel] Forwarded message about FPC status I see no way to speed up the 2.x FPC significantly only by stripping something down or whatever. The whole 2.x design is geared towards portability and maintainability, speed is only 2nd level goal (and being honest, self compilation in ~10 sec even on my 5 year old Core 2 Duo is not that bad ;)). I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the compiler on windows was at least a few minutes. That's likely because of the slower process startup time of Windows. Also the GNU utilities we use (make, etc.) aren't the fastest on Windows either. Also command line output can slow down things dramatically (cmd.exe or the PowerShell aren't that fast). what I *think* is a large hog on compilation/linking is the spawning of multiple executables in the different steps as opposed to the monolithic exe(+dll) that dcc32.exe is. If you use the internal assembler and linker on Windows you get the same. The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. lovely, but isn't that what Embarcadero is doing for their future compiler? Using the llvm toolchain, they will provide a front compiler to an intermediate language or interpreted code. Then they have a few optimisations for the middle layer and use the back-ends that are already available to make stuff architecturally compile to whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or custom backend) But it is very likely that they won't gain a speed advantage by that. They need to decouple their frontend from their backend and here it is very likely that they get a performance penalty if they need to go through some indirections or callbacks to get the necessary information from frontend to backend (or they need to stuff all information potentially needed by the backend into the backend). Basically the same that FPC does... Also LLVM does not support that many backends. Currently the most important ones are x86(_64), ARM and PowerPC. What LLVM definitely does not support is m68k... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
On Tuesday 25 December 2012 18:01:50 Florian Klaempfl wrote: Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. I use this machine often so I am forced to write efficient code for MSEgui and my projects. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. AFAIK Delphi 7 does not need such an approach so I hope there is room for optimizations in FPC. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Florian Klaempfl wrote: Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. I've got machines which are older than that, but they've almost all got multiple processors. I can't remember the exact timing, but a Sun machine with 16x 80MHz chips would build the Linux kernel in a minute or so, so parallelisation at the make -j level can be a big win. Obviously that doesn't help if somebody's running native builds on an obscure development board, or if a multi-CPU/core architecture's got very poor aggregate I/O performance, or if certain aspects of SMP quite simply aren't reliable (lack of cache coherence on some MIPS systems). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM
The IR changes syntax often, so using that will most likely cause version problems. The other option is to use C++ classes directly which apparently is more stable. I know i386, x86_64 and ARM works pretty good. I don't know about the few others. Compiling speed is very, very slow :) (when using ir input at least) Having worked a bit with llvm I don't like the IDE of completely changing the backend of fpc. Mostly because we are then relying on a bunch of C++ programmers to fix bugs and extend the backend in the future. Regards Jeppe Johansen - Reply message - From: Martin Schreiber mse00...@gmail.com Date: Wed, Dec 26, 2012 06:07 Subject: [fpc-devel] LLVM To: fpc-devel@lists.freepascal.org Hi, Does any body work on a LLVM backend for Free Pascal? Has anybody experience with LLVM? Are there licensing issues? What about the quality of the produced code? What about compiling speed? Thoughts? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
