Sometime ago, there was a brief mention of multi-threading FPC would be
counter productive because compilation process was mostly disk IO bound
--this is what I understood anyway.
I wanted to check to see if disk IO was really limiting FPC/Lazarus
compile performance.
The only quick way I
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 10 Sep 2010, at 17:43, Adem wrote:
SSD: 103,060 ms (1 min 43 sec)
RAMDisk: 105,463 ms (1 min 46 sec)
This doesn't make sense. FPC/Lazarus compiles on the faster medium
longer (albeit only 3 sec.).
Everything on your SSD is cached in RAM, so it's normal that both are
about the same
On 2010-09-10 06:54 PM, Jonas Maebe wrote:
On 10 Sep 2010, at 17:43, Adem wrote:
SSD: 103,060 ms (1 min 43 sec)
RAMDisk: 105,463 ms (1 min 46 sec)
This doesn't make sense. FPC/Lazarus compiles on the faster medium
longer (albeit only 3 sec.).
I am sorry, but what you've just said doesn't
On 10 Sep 2010, at 18:05, Adem wrote:
On 2010-09-10 06:54 PM, Jonas Maebe wrote:
On 10 Sep 2010, at 17:43, Adem wrote:
SSD: 103,060 ms (1 min 43 sec)
RAMDisk: 105,463 ms (1 min 46 sec)
This doesn't make sense. FPC/Lazarus compiles on the faster medium
longer (albeit only 3 sec.).
Every
In our previous episode, Adem said:
> I wanted to check to see if disk IO was really limiting FPC/Lazarus
> compile performance.
> The only quick way I could devise to check this was to use two different
> disks which are significantly different from one another in terms of
> performance.
Both
AFAIR the ATTO tool measures read and write bursts of single "files" X in size.
An interesting exercise is to transfer 1000 files to a USB memory
stick in 2 situations:
- Compacted in a single file, transfers at or near full USB speed.
- Spread out normally on a folder takes forever.
This happen
On 2010-09-10 07:16 PM, Daniel wrote:
This happens because the time it takes to SWITCH between one file to
another is significant. Ending one operation (a single file transfer)
and begining another takes a time slice. Summing up all these start
and finish ops takes a significant time slice.
I wo
On Friday 10 September 2010 17:43:59 Adem wrote:
> Sometime ago, there was a brief mention of multi-threading FPC would be
> counter productive because compilation process was mostly disk IO bound
> --this is what I understood anyway.
>
> I wanted to check to see if disk IO was really limiting FPC/
On 11 Sep 2010, at 08:55, Martin Schreiber wrote:
> Interesting is that Delphi 7 compiles about 10 times faster than FPC on the
> same machine.
> http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html
> Results with more code and FPC 2.4:
> http://thread.gmane.org/gmane.comp.
On Saturday, 11. September 2010 11.32:38 Jonas Maebe wrote:
>
> So yes, FPC is slower than Delphi. Would parallelising FPC reduce the speed
> gap?
Because the gap is so big I think not substantial.
Given that (please correct me if I am wrong):
- FPC bottleneck is disk IO and not compiler logic a
On Saturday 11 September 2010 09:55:14 Martin Schreiber wrote:
> On Friday 10 September 2010 17:43:59 Adem wrote:
> > Sometime ago, there was a brief mention of multi-threading FPC would be
> > counter productive because compilation process was mostly disk IO bound
> > --this is what I understood a
On 11 Sep 2010, at 12:23, Martin Schreiber wrote:
> or it isn't true that FPC bottleneck is disk IO. Are we absolutely sure about
> the bottleneck?
I'm quite certain that there are many reasons that FPC compiles more slowly
than Delphi. The bottlenecks probably also vary from platform to platf
On Saturday, 11. September 2010 12.25:14 Juha Manninen (gmail) wrote:
> > One would think Delphi and FPC need the same disk IO?
>
> I read the threads. My guess is also that the slowness comes from searching
> and writing many files in big directory structures. It is slow even if the
> files are ca
On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote:
> And why does the Delphi commandline compiler (dcc32) not need this IDE
> assistance?
My guess is that dcc32 works as an integrated make program + compiler and thus
doesn't start external processes for each file.
Or, if it starts an
Jonas Maebe пишет:
On 11 Sep 2010, at 12:23, Martin Schreiber wrote:
or it isn't true that FPC bottleneck is disk IO. Are we absolutely sure about
the bottleneck?
I'm quite certain that there are many reasons that FPC compiles more slowly than Delphi.
The bottlenecks probably also vary from
On Sat, 11 Sep 2010, Juha Manninen (gmail) wrote:
On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote:
And why does the Delphi commandline compiler (dcc32) not need this IDE
assistance?
My guess is that dcc32 works as an integrated make program + compiler and thus
doesn't start ex
On Sat, 11 Sep 2010, Sergei Gorelkin wrote:
Jonas Maebe пишет:
On 11 Sep 2010, at 12:23, Martin Schreiber wrote:
or it isn't true that FPC bottleneck is disk IO. Are we absolutely sure
about the bottleneck?
I'm quite certain that there are many reasons that FPC compiles more slowly
than
On Sat, 11 Sep 2010 16:02:52 +0200 (CEST)
Michael Van Canneyt wrote:
>
>
> On Sat, 11 Sep 2010, Juha Manninen (gmail) wrote:
>
> > On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote:
> >> And why does the Delphi commandline compiler (dcc32) not need this IDE
> >> assistance?
> >
> >
Michael Van Canneyt пишет:
One idea that comes at this point is to put PPU data directly into
object files, so the number of output files is reduced plain twice.
The PPU data could be placed into a section that is ignored by linker.
However I don't know is this is possible for all platforms.
On 11 September 2010 16:12, Mattias Gaertner wrote:
>
> Martin, can you give a comparison between win32 and Linux 32?
Add to that Martin, I know MSEgui is compilable with FPC and
Delphi. Is MSEgui compilable with Kylix 3 too? Then one could do a
Delphi 7 vs Kylix 3 comparison as well - seeing
On Saturday, 11. September 2010 18.37:49 Graeme Geldenhuys wrote:
> On 11 September 2010 16:12, Mattias Gaertner wrote:
> > Martin, can you give a comparison between win32 and Linux 32?
>
> Add to that Martin, I know MSEgui is compilable with FPC and
> Delphi. Is MSEgui compilable with Kylix 3
On Saturday, 11. September 2010 16.12:10 Mattias Gaertner wrote:
>
> Maybe dcc32 likes the MSEgui sources.
>
Or maybe FPC does not like MSEgui sources. ;-)
> Martin, can you give a comparison between win32 and Linux 32?
>
I don't have a working Kylix 3 environment at the moment. IIRC dcc32 on Linu
Am 11.09.2010 19:50, schrieb Martin Schreiber:
> On Saturday, 11. September 2010 16.12:10 Mattias Gaertner wrote:
>>
>> Maybe dcc32 likes the MSEgui sources.
>>
> Or maybe FPC does not like MSEgui sources. ;-)
>
>> Martin, can you give a comparison between win32 and Linux 32?
>>
> I don't have a w
On Sat, 11 Sep 2010 19:50:41 +0200
Martin Schreiber wrote:
> On Saturday, 11. September 2010 16.12:10 Mattias Gaertner wrote:
> >
> > Maybe dcc32 likes the MSEgui sources.
> >
> Or maybe FPC does not like MSEgui sources. ;-)
>
> > Martin, can you give a comparison between win32 and Linux 32?
> >
On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
>
> What machine? Because with hot disk cache, I just build MSEide in about
> 10 s (15 s cold) on W7 64 Bit:
>
The same as for all other tests,
win2000, AMD Athlon XP 3000+, 1GB RAM
> ...
> Linking mseidefp.exe
> 308574 lines compiled,
Am 11.09.2010 20:50, schrieb Martin Schreiber:
> On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
>>
>> What machine? Because with hot disk cache, I just build MSEide in about
>> 10 s (15 s cold) on W7 64 Bit:
>>
> The same as for all other tests,
> win2000, AMD Athlon XP 3000+, 1GB RA
Am 11.09.2010 22:04, schrieb Jonas Maebe:
>
> On 11 Sep 2010, at 21:10, Florian Klämpfl wrote:
>
>> Anyways, before this ends in an endless discussion: if anybody is
>> interested in improving FPC compilation speed (for my needs is
>> sufficient) and have a look at fillchar and, have a look at
On 11 September 2010 21:10, Florian Klämpfl wrote:
FPC
---
>>> Linking mseidefp.exe
>>> 308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data
>>
Delphi
-
> mseide.pas(63)
> 280491 lines, 2.18 seconds, 2110568 bytes code, 752073 bytes data.
Now this is weird! Any
- "Martin Schreiber" schreef:
> On Saturday, 11. September 2010 12.25:14 Juha Manninen (gmail) wrote:
> > > One would think Delphi and FPC need the same disk IO?
> >
> > I read the threads. My guess is also that the slowness comes from
> searching
> > and writing many files in big directory
- "Juha Manninen (gmail)" schreef:
> On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote:
> > And why does the Delphi commandline compiler (dcc32) not need this
> IDE
> > assistance?
>
> My guess is that dcc32 works as an integrated make program + compiler
> and thus
> doesn't st
- "Michael Van Canneyt" schreef:
> On Sat, 11 Sep 2010, Juha Manninen (gmail) wrote:
>
> > On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote:
> >> And why does the Delphi commandline compiler (dcc32) not need this
> IDE
> >> assistance?
> >
> > My guess is that dcc32 works as an
- "Florian Klämpfl" schreef:
> Am 11.09.2010 20:50, schrieb Martin Schreiber:
> > On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
> >>
> >> What machine? Because with hot disk cache, I just build MSEide in
> about
> >> 10 s (15 s cold) on W7 64 Bit:
> >>
> > The same as for all
On Sunday, 12. September 2010 01.31:43 Dimitri Smits wrote:
> >
> > And why does the Delphi commandline compiler (dcc32) not need this IDE
> >
> > assistance?
>
> it does. Delphi IDE passes extra assumptions/directories that the
> commandline tool does not know about (for instance $(DELPHI)/Project
On Saturday, 11. September 2010 21.10:20 Florian Klämpfl wrote:
>
> Anyways, before this ends in an endless discussion: if anybody is
> interested in improving FPC compilation speed (for my needs is
> sufficient) and have a look at fillchar and, have a look at FPC's unit
> loading algorithm (not th
Am 12.09.2010 00:20, schrieb Graeme Geldenhuys:
Now this is weird! Anybody else spotted the difference? Delphi seems
to compile +-28000 lines less that FPC! Florian, I presume it's the
same machine with the same MSEgui source code revision? What would be
the reason for that?
Would that (lines c
On Sun, 12 Sep 2010 07:33:55 +0200
Martin Schreiber wrote:
> On Saturday, 11. September 2010 21.10:20 Florian Klämpfl wrote:
> >
> > Anyways, before this ends in an endless discussion: if anybody is
> > interested in improving FPC compilation speed (for my needs is
> > sufficient) and have a look
Am 12.09.2010 07:33, schrieb Martin Schreiber:
> On Saturday, 11. September 2010 21.10:20 Florian Klämpfl wrote:
>>
>> Anyways, before this ends in an endless discussion: if anybody is
>> interested in improving FPC compilation speed (for my needs is
>> sufficient) and have a look at fillchar and,
Am 12.09.2010 01:20, schrieb Graeme Geldenhuys:
> On 11 September 2010 21:10, Florian Klämpfl wrote:
>
> FPC
> ---
Linking mseidefp.exe
308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data
>>>
>
> Delphi
> -
>> mseide.pas(63)
>> 280491 lines, 2.18 second
On Sunday, 12. September 2010 10.12:59 Florian Klämpfl wrote:
> >
> > Agreed. My opinion is that before we start to implement difficult and
> > error-prone multi-threading into FPC we should find out why the hell
> > Delphi 7 can compile so much faster
>
> Because of the same reason why it seems to
In our previous episode, Mattias Gaertner said:
> > Agreed. My opinion is that before we start to implement difficult and
> > error-prone multi-threading into FPC we should find out why the hell Delphi
> > 7
> > can compile so much faster and produces even better code?
>
> Seeing that dcc is on
Am 12.09.2010 10:21, schrieb Martin Schreiber:
> On Sunday, 12. September 2010 10.12:59 Florian Klämpfl wrote:
>>>
>>> Agreed. My opinion is that before we start to implement difficult and
>>> error-prone multi-threading into FPC we should find out why the hell
>>> Delphi 7 can compile so much fast
On Sunday, 12. September 2010 10.29:32 Florian Klämpfl wrote:
> >
> > And that results in a discrepancy of factor 5..10? I can't believe it.
>
> Digging out 1.0.10 and using some extreme example:
>
> C:\fpc\tests\webtbs>"c:\pp 1.0.10\bin\win32\ppc386.exe" tw2242 -O2
> Free Pascal Compiler version 1
In our previous episode, Martin Schreiber said:
> > Anyways, before this ends in an endless discussion: if anybody is
> > interested in improving FPC compilation speed (for my needs is
> > sufficient) and have a look at fillchar and, have a look at FPC's unit
> > loading algorithm (not the actual i
In our previous episode, Florian Kl?mpfl said:
> Digging out 1.0.10 and using some extreme example:
>
> C:\fpc\tests\webtbs>"c:\pp 1.0.10\bin\win32\ppc386.exe" tw2242 -O2
> Free Pascal Compiler version 1.0.10 [2003/06/27] for i386
> Copyright (c) 1993-2003 by Florian Klaempfl
> Target OS: Win32 fo
On 12 Sep 2010, at 10:39, Martin Schreiber wrote:
> On Sunday, 12. September 2010 10.29:32 Florian Klämpfl wrote:
>>>
>>> And that results in a discrepancy of factor 5..10? I can't believe it.
>>
>> Digging out 1.0.10 and using some extreme example:
>>
>> C:\fpc\tests\webtbs>"c:\pp 1.0.10\bin\
Am 12.09.2010 10:39, schrieb Martin Schreiber:
> On Sunday, 12. September 2010 10.29:32 Florian Klämpfl wrote:
>>>
>>> And that results in a discrepancy of factor 5..10? I can't believe it.
>>
>> Digging out 1.0.10 and using some extreme example:
>>
>> C:\fpc\tests\webtbs>"c:\pp 1.0.10\bin\win32\pp
On 12 Sep 2010, at 10:43, Marco van de Voort wrote:
> I'm no expert on profiling the compiler, but if I read the various threads
> over the years I see defensive and conflicting statements:
>
> In discussions with Hans, it is said that I/O is not a factor, since after
> one run everything is cac
On 12 Sep 2010, at 11:41, Jonas Maebe wrote:
> There's a free profiler for Windows by AMD:
> http://developer.amd.com/cpu/codeanalyst/Pages/default.aspx
And by Microsoft: http://msdn.microsoft.com/en-us/performance/cc825801.aspx
Jonas___
fpc-devel m
On Sun, 12 Sep 2010 10:25:22 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said:
> > > Agreed. My opinion is that before we start to implement difficult and
> > > error-prone multi-threading into FPC we should find out why the hell
> > > Del
In our previous episode, Mattias Gaertner said:
> > > Seeing that dcc is only 800K:
> > > maybe it fits into the cpu cache.
> >
> > I assume dcc.exe uses more data than code :-)
>
> CPU caches do not work FIFO.
I assume not, since the administration overhead would be too large.
> If FPC does n
Am 12.09.2010 10:12, schrieb Florian Klämpfl:
The 2.x register allocator is more robust (no more internalerrors 10),
it is small (basically 2k lines, compiler/rgobj.pas) and it generates
reasonable register allocations on all types of CPUs (remember, FPC
supports CPUs with high register pressure
Martin Schreiber пишет:
Truncated at line 16380:
Delphi 7:
E:\FPC\svn\fixes_2_4\tests\webtbf>dcc32 tw2242xtrunc.pp
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation
tw2242xtrunc.pp(16382)
16383 lines, 0.16 seconds, 256684 bytes code, 1801 bytes data.
FPC:
E:\FPC\s
On 12 Sep 2010, at 14:50, Martin Schreiber wrote:
> Hmm. ;-)
> Please take it with humor. :-)
No humor is necessary. Delphi probably uses a linear scan register allocator,
which (as I mentioned before) in general generates somewhat worse code in the
general case (assuming an implementation of
On 12 Sep 2010, at 16:15, Jonas Maebe wrote:
> On 12 Sep 2010, at 14:50, Martin Schreiber wrote:
>
> On 12 Sep 2010, at 16:10, Sergei Gorelkin wrote:
>
>> Does that happen because of the SSA? I mean, it looks like a new register is
>> allocated for every statement until limit of 16384 is hit.
- "Marco van de Voort" schreef:
> I partially agree with you in the fact that the exact reasons are not
> known.
>
> I'm no expert on profiling the compiler, but if I read the various
> threads
> over the years I see defensive and conflicting statements:
>
> In discussions with Hans, it is
Am 12.09.2010 18:24, schrieb Dimitri Smits:
>
> - "Marco van de Voort" schreef:
>
>> I partially agree with you in the fact that the exact reasons are
>> not known.
>>
>> I'm no expert on profiling the compiler, but if I read the various
>> threads over the years I see defensive and confli
Am 12.09.2010 14:50, schrieb Martin Schreiber:
>
> FPC:
> E:\FPC\svn\fixes_2_4\tests\webtbf>ppc386 tw2242x.pp
> Free Pascal Compiler version 2.4.0 [2009/12/18] for i386
> Copyright (c) 1993-2009 by Florian Klaempfl
> Target OS: Win32 for i386
> Compiling tw2242x.pp
> tw2242x.pp(16386,7) Fatal: Pr
On Sunday, 12. September 2010 18.29:34 Florian Klämpfl wrote:
>
> > Please take it with humor. :-)
>
> As long as the compiler itself builds on a reasonable machine in less
> than 10 seconds, I'am happy :)
Yup, I know. But there are people who use FPC for other tasks than compiling
FPC and there
In our previous episode, Dimitri Smits said:
> > after
> > one run everything is cached anyway, and then in this thread I/O is to
> > blame
> > for a huge difference in speed.
>
> that may be the case for reading, not necessarily for the files being
> written. in ppu.pas, everything you "put" res
In our previous episode, Jonas Maebe said:
> > I'm no expert on profiling the compiler, but if I read the various threads
> > over the years I see defensive and conflicting statements:
> >
> > In discussions with Hans, it is said that I/O is not a factor, since after
> > one run everything is cach
On 9/12/2010 12:41 PM, Jonas Maebe wrote:
In discussions with Hans, it is said that I/O is not a factor, since after
one run everything is cached anyway, and then in this thread I/O is to blame
for a huge difference in speed.
Disk throughput doesn't really matter. Reading directory contents, ge
On 9/12/2010 12:53 PM, Jonas Maebe wrote:
On 12 Sep 2010, at 11:41, Jonas Maebe wrote:
There's a free profiler for Windows by AMD:
http://developer.amd.com/cpu/codeanalyst/Pages/default.aspx
And by Microsoft: http://msdn.microsoft.com/en-us/performance/cc825801.aspx
It's a 2.5G download --
On 12 Sep 2010, at 19:05, Adem wrote:
> On 9/12/2010 12:53 PM, Jonas Maebe wrote:
>> On 12 Sep 2010, at 11:41, Jonas Maebe wrote:
>>
>>> There's a free profiler for Windows by AMD:
>>> http://developer.amd.com/cpu/codeanalyst/Pages/default.aspx
>> And by Microsoft: http://msdn.microsoft.com/en-
- "Mattias Gaertner" schreef:
> On Sun, 12 Sep 2010 10:25:22 +0200 (CEST)
> mar...@stack.nl (Marco van de Voort) wrote:
>
> > In our previous episode, Mattias Gaertner said:
> > > > Agreed. My opinion is that before we start to implement
> difficult and
> > > > error-prone multi-threading
Am 12.09.2010 18:39, schrieb Martin Schreiber:
> On Sunday, 12. September 2010 18.29:34 Florian Klämpfl wrote:
>>
>>> Please take it with humor. :-)
>>
>> As long as the compiler itself builds on a reasonable machine in less
>> than 10 seconds, I'am happy :)
>
> Yup, I know. But there are people w
On 12 Sep 2010, at 19:15, Dimitri Smits wrote:
> - "Mattias Gaertner" schreef:
>
>> CPU caches do not work FIFO.
>> If FPC does not fit into the CPU cache, then the CPU has to
>> constantly load code mem additionally to the data.
>>
> in that case, can splitting up the .exe into .exe + mor
On Sun, 12 Sep 2010 19:15:29 +0200 (CEST)
Dimitri Smits wrote:
>
> - "Mattias Gaertner" schreef:
>
> > On Sun, 12 Sep 2010 10:25:22 +0200 (CEST)
> > mar...@stack.nl (Marco van de Voort) wrote:
> >
> > > In our previous episode, Mattias Gaertner said:
> > > > > Agreed. My opinion is that b
On 9/12/2010 8:14 PM, Jonas Maebe wrote:
Besides, FPC on Windows does not start any other executables when compiling
programs
You might be making a distinction (between compiling and building) here,
but when I press 'rebuild lazarus' on that menu, here the list
executables of executables cal
On 12 Sep 2010, at 23:01, Adem wrote:
> On 9/12/2010 8:14 PM, Jonas Maebe wrote:
>> Besides, FPC on Windows does not start any other executables when compiling
>> programs
>>
> You might be making a distinction (between compiling and building) here,
> but when I press 'rebuild lazarus' on that
Florian Klämpfl schrieb:
This is a very specific example which allows to explain rather simple
the slowness of 2.x: The reason is a decision geared by maintainability
and portability: 2.x uses a so-called graph colouring register allocator
while 1.x used a pretty simple register allocator specif
Am 13.09.2010 23:38, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
>> This is a very specific example which allows to explain rather simple
>> the slowness of 2.x: The reason is a decision geared by maintainability
>> and portability: 2.x uses a so-called graph colouring register allo
Florian Klämpfl schrieb:
Anyways, before this ends in an endless discussion: if anybody is
interested in improving FPC compilation speed (for my needs is
sufficient) and have a look at fillchar
IMO not FillChar is the bottleneck, instead it's the access to newly
allocated memory in/around Ini
73 matches
Mail list logo
