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
On Sun, 12 Sep 2010, Willibald Krenn wrote:
Hi!
Today I was thinking about fpc packages (whenever I am using this word, I
mean Delphi-style-DLL-packages) and what difficulties might arise when
implementing them. In my opinion, doing packages for D6-like Pascal should
not be conceptually
In our previous episode, Willibald Krenn said:
the correctness of the use of a value with a generic type without the
need for specialization. Here is a catch: Pascal has quite a lot of
types that are not classes. And this makes things a bit uncomfortable.
I would say that it is (almost)
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
Michael Van Canneyt schrieb:
Packages have nothing to do with the language feature. The difficult thing
is run-time resolving of all symbols. What the nature is of these
symbols is really not relevant.
Pardon my ignorance, but why is runtime resolving so difficult? There is
a fine Delphi
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
Marco van de Voort schrieb:
No it won't. Not all of the implementation of a package needs to be in the
.BPL equivalent. Neither is the case in Delphi.
Seek for $weakpackage and read the packages wiki again
In words of Borland/Embac - Unit files containing the {$WEAKPACKAGEUNIT
ON}
In our previous episode, Willibald Krenn said:
No it won't. Not all of the implementation of a package needs to be in the
.BPL equivalent. Neither is the case in Delphi.
Seek for $weakpackage and read the packages wiki again
In words of Borland/Embac - Unit files containing the
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:
Marco van de Voort schrieb:
No, since any specialization creates the actual types, and they all will
have their respective static fields anyway? (since the static field can be
of the variable type)
There are some languages/runtimes that have some damage control here (most
notably C# which uses
Hi all,
Seems like that after all these years there are still bugs in fpc's
makefiles...
When you install a package, not the Package.fpc which is generated for
the whole package, but the Package.fpc generated for the last
sub-package is installed into
xxx/version/units/target/packagename.
In our previous episode, Willibald Krenn said:
There are some languages/runtimes that have some damage control here (most
notably C# which uses constraints to limit the definition to classes
implementing a certain interface, and it is said to typically share
specializations for such
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
Marco van de Voort schrieb:
Played around with Delphi today, and it seems that class vars are
somewhat broken on generic types. They work as expected (share common
class value amongst all sameclasssametype instances) only in a unit
scope, it seems. Which is a pitty.
To be honest, that is
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,
43 matches
Mail list logo
