___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
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
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
On Sun, 12 Sep 2010 07:33:55 +0200
Martin Schreiber mse00...@gmail.com 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
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, have a
Am 12.09.2010 01:20, schrieb Graeme Geldenhuys:
On 11 September 2010 21:10, Florian Klämpfl flor...@freepascal.org 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
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 take
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 only 800K:
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 faster
Because
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\webtbsc:\pp 1.0.10\bin\win32\ppc386.exe tw2242 -O2
Free Pascal Compiler version 1.0.10
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/o
In our previous episode, Florian Kl?mpfl said:
Digging out 1.0.10 and using some extreme example:
C:\fpc\tests\webtbsc:\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 for i386
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\webtbsc:\pp 1.0.10\bin\win32\ppc386.exe
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\webtbsc:\pp 1.0.10\bin\win32\ppc386.exe tw2242
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 cached
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
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
Delphi 7
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 not fit into
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
Martin Schreiber пишет:
Truncated at line 16380:
Delphi 7:
E:\FPC\svn\fixes_2_4\tests\webtbfdcc32 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:
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.
No,
- Marco van de Voort mar...@stack.nl 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,
Am 12.09.2010 18:24, schrieb Dimitri Smits:
- Marco van de Voort mar...@stack.nl 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
Am 12.09.2010 14:50, schrieb Martin Schreiber:
FPC:
E:\FPC\svn\fixes_2_4\tests\webtbfppc386 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: Procedure
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 are
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 results in a
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 cached
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,
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:
- Mattias Gaertner nc-gaert...@netcologne.de 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
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 who use FPC
On 12 Sep 2010, at 19:15, Dimitri Smits wrote:
- Mattias Gaertner nc-gaert...@netcologne.de 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
On Sun, 12 Sep 2010 19:15:29 +0200 (CEST)
Dimitri Smits smi...@telenet.be wrote:
- Mattias Gaertner nc-gaert...@netcologne.de 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:
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
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 menu,
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
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:
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 and
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 anyway.
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
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 cached.
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
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 mich...@freepascal.org 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
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
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 too?
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 Linux
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 working Kylix
On Sat, 11 Sep 2010 19:50:41 +0200
Martin Schreiber mse00...@gmail.com 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
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, 10.6
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 RAM
...
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 FPC's
On 11 September 2010 21:10, Florian Klämpfl flor...@freepascal.org 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
- Martin Schreiber mse00...@gmail.com 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
- Juha Manninen (gmail) juha.mannine...@gmail.com 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
- Michael Van Canneyt mich...@freepascal.org 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
- Florian Klämpfl flor...@freepascal.org 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
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)/Projects/Bpl).
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 the
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
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
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.).
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 are
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 happens
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
71 matches
Mail list logo
