Re: [fpc-devel] Forwarded message about FPC statusy
Am 26.12.2012 05:42, schrieb Martin Schreiber: 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 Indeed, it probably (judging from the difficulties embarcadero apparently had to have x86-64 and arm support) sacrificed flexibility, portability (e.g. still no arm yet afaik, 64 bit support took years) and maintainability instead. so I hope there is room for optimizations in FPC. Better start from scratch then. FPC is not designed to be fast at any cost. Tiny C might be a good starting point. ___ 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 26.12.2012 05:42, Martin Schreiber wrote: 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. Did you even read what we wrote? The mere fact that FPC's backend is more seperated from it's frontend than Delphi's was till XE2 is very likely one of the biggest performance problems FPC has. And this must be compensated in unusal ways like Florian described. Otherwise you'd need to go back to the way that pre-1.9 FPC worked and I don't think anyone of the FPC devs wants that. You'd basically need to rewrite the complete compiler as it is currently geared towards that seperation. 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 Wednesday 26 December 2012 12:41:42 Sven Barth wrote: On 26.12.2012 05:42, Martin Schreiber wrote: 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. Did you even read what we wrote? The mere fact that FPC's backend is more seperated from it's frontend than Delphi's was till XE2 is very likely one of the biggest performance problems FPC has. And this must be compensated in unusal ways like Florian described. Otherwise you'd need to go back to the way that pre-1.9 FPC worked and I don't think anyone of the FPC devs wants that. You'd basically need to rewrite the complete compiler as it is currently geared towards that seperation. Sven, no offending meant, but I know how the FPC RTL, FCL and compiler is programmed. There *is* room for improvement. ;-) 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
On Wed, 26 Dec 2012, Martin Schreiber wrote: On Wednesday 26 December 2012 12:41:42 Sven Barth wrote: On 26.12.2012 05:42, Martin Schreiber wrote: 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. Did you even read what we wrote? The mere fact that FPC's backend is more seperated from it's frontend than Delphi's was till XE2 is very likely one of the biggest performance problems FPC has. And this must be compensated in unusal ways like Florian described. Otherwise you'd need to go back to the way that pre-1.9 FPC worked and I don't think anyone of the FPC devs wants that. You'd basically need to rewrite the complete compiler as it is currently geared towards that seperation. Sven, no offending meant, but I know how the FPC RTL, FCL and compiler is programmed. There *is* room for improvement. ;-) If you think so, please make some suggestions. We've had a suggestion about pooling (which gains us 10-20%), and it didn't come from you. Florian suggested a daemon kind of approach. Also not your proposal. Till now you present only critique, claims that you can do better. But you offer no constructive advice, unless I have missed it. 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
Mark Morgan Lloyd schrieb: 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. C is very different from Pascal, WRT parallel compilation. C/C++ use independent header files, so that *all* modules can be compiled in parallel. OPL instead must compile all used units, before compilation of a module can proceed. This will at least result in a long startup phase, where the basic units are compiled almost sequentially, before parallel compilation may begin. Both languages use similar means for speeding up compilation. C compilers use precompiled headers, while Pascal compilers use the DCU/PPU files to reduce parsing efforts. This will give C an big kick, because preprocessing and parsing the source code is a lot of work. I'm not sure about the impact on Pascal, though. DoDi ___ 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 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 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 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 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 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 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 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 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 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
