Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 compiled) also account for the huge difference in bytes data. What is the final executable size (not that this matters much to me) generated by the two compilers? Martin, do you get the same results for lines compiled? MSEide Delphi version has no DB components. In order to switch off non Delphi components in FPC mode some defines must be set. This is with MSEide+MSEgui SVN trunk rev.3910: Delphi: 280496 lines, 4.49 seconds, 2127360 bytes code, 752073 bytes data. 12.09.2010 07:013'129'856 mseide.exe FPC 2.4.0: 281604 lines compiled, 40.2 sec , 2136496 bytes code, 1541192 bytes data 12.09.2010 07:093'687'228 mseidefp.exe FPC 2.4.0 with debug info: 281604 lines compiled, 54.4 sec , 2142896 bytes code, 1541336 bytes data 12.09.2010 07:16 41'759'691 mseidefp.exe Commandline Delphi: dcc32 -B -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\..\lib\common\kernel\i386-win32 -U..\..\lib\common\image -U..\..\lib\common\widgets -U..\..\lib\common\designutils -U..\..\lib\common\sysutils -U..\..\lib\common\editwidgets -U..\..\lib\common\dialogs -U..\..\lib\common\regcomponents -U..\..\lib\common\serialcomm -U..\..\lib\common\printer -U..\..\lib\common\ifi -U..\..\lib\common\math -dmse_no_db -dmse_no_opengl mseide.pas Commandline FPC: ppc386.exe -O2 -CX -XX -Xs -B -I..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 -Fu..\..\lib\common\image -Fu..\..\lib\common\widgets -Fu..\..\lib\common\designutils -Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\..\lib\common\serialcomm -Fu..\..\lib\common\printer -Fu..\..\lib\common\ifi -Fu..\..\lib\common\math -dmse_no_db -dmse_no_opengl -omseidefp.exe mseide.pas Commandline FPC with ddebug info: ppc386.exe -O2 -CX -XX -gl -B -I..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\kernel\i386-win32 -Fu..\..\lib\common\image -Fu..\..\lib\common\widgets -Fu..\..\lib\common\designutils -Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\..\lib\common\serialcomm -Fu..\..\lib\common\printer -Fu..\..\lib\common\ifi -Fu..\..\lib\common\math -dmse_no_db -dmse_no_opengl -omseidefp.exe mseide.pas Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 have a look at fillchar and, have a look at FPC's unit loading algorithm (not the actual i/o itself but how all the symbols classes etc. are restored). This two points are bottlenecks which might help when they are improved, though it's pretty unlikely that this will improve things more than a few percent. 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: maybe it fits into the cpu cache. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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 hard. It'll be more of a technical challenge to fiddle with the compiler internals. [snip] So I am of the opinion that 'real' generics would make packages possible: Yes, generated code might be less efficient (int64 implementation for all signed ordinals), or there might be code duplication (for each ordinal type one implementation), but things would work. With the current implementation of generics packages are a no-go, I am afraid. 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. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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) impossible to do packages in a sane way if we allow all sorts of operations on 'generically typed' values: If someone defines such a generic class, the compiler will need to pre-generate all possible type specializations of that class for the package file 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 So in short, everything in the units that doesn't go into the DLL goes into the .DCP which is more or less a dcu archive if I understood it correctly So only the specializations used inside the code contained in the BPL (and maybe one or two that you could force to save duplication) are in the BPL. So in short, the problem is one that you create yourself by self-inflicting that every piece of code _must_ be in the BPL. That isn't the case. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 look at FPC's unit loading algorithm (not the actual i/o itself but how all the symbols classes etc. are restored). This two points are bottlenecks which might help when they are improved, though it's pretty unlikely that this will improve things more than a few percent. 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 years to port delphi to 64 bit: different design goals. It seems speed were the only design goal, nobody took care about maintainability or portability. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 seconds, 2110568 bytes code, 752073 bytes data. 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? Ifdef'ed unit usage/includes? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 years to port delphi to 64 bit: different design goals. It seems speed were the only design goal, nobody took care about maintainability or portability. And that results in a discrepancy of factor 5..10? I can't believe it. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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: maybe it fits into the cpu cache. I assume dcc.exe uses more data than code :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 of the same reason why it seems to take years to port delphi to 64 bit: different design goals. It seems speed were the only design goal, nobody took care about maintainability or portability. 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 [2003/06/27] for i386 Copyright (c) 1993-2003 by Florian Klaempfl Target OS: Win32 for i386 Compiling tw2242.pp Linking tw2242.exe 13083 Lines compiled, 0.8 sec C:\fpc\tests\webtbsfpc tw2242 -O2 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 tw2242.pp Linking tw2242.exe 13083 lines compiled, 4.7 sec , 301376 bytes code, 1864 bytes data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 [2003/06/27] for i386 Copyright (c) 1993-2003 by Florian Klaempfl Target OS: Win32 for i386 Compiling tw2242.pp Linking tw2242.exe 13083 Lines compiled, 0.8 sec C:\fpc\tests\webtbsfpc tw2242 -O2 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 tw2242.pp Linking tw2242.exe 13083 lines compiled, 4.7 sec , 301376 bytes code, 1864 bytes data Impressive. Now we can hook in. Where is the difference? What makes 2.4.0 so much slower? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 itself but how all the symbols classes etc. are restored). This two points are bottlenecks which might help when they are improved, though it's pretty unlikely that this will improve things more than a few percent. 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? 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 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. The same with the fact that we use shortstring for performance in many places where delphi in fact allows longer mangled names and is faster. That leaves the maintainability bit. I think that is certainly true, and it probably can be tweaked to be a bit better. It won't be easy though and is more likely to be a lot of things that add a little than few that matter a lot. Which makes it a permanent positions instead of a one-off effort. Any takers? As far as the I/O performance discussion goes, some observations: - To find something interesting, probably the test has to be done for various sizes of code. To see if maybe some startup factor (Rather than actual processing) is a cause. - FPC has to read at least twice the number of files (.ppu/.o). So if opening or number of files in the dir path is a factor, it will do worse by default. - Possibily, a defaultly installed windows searches through a larger unit path (more dirs, more file) than Delphi _default_ - For that to be found, more has to be known about dcc.cfg during the tests. - THis means that tests will have to be repeated with various sizes of unitpath trees (both dirs and files) to see if this is a discussion. - Most profiling recently afaik has been done by Jonas, and thus not on Windows. Yet the delphi comparisons are on windows. - Actually linking should be avoided in the test. It might obscure things. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 Compiling tw2242.pp Linking tw2242.exe 13083 Lines compiled, 0.8 sec C:\fpc\tests\webtbsfpc tw2242 -O2 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 tw2242.pp Linking tw2242.exe 13083 lines compiled, 4.7 sec , 301376 bytes code, 1864 bytes data Do both numbers include linking ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 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 Compiling tw2242.pp Linking tw2242.exe 13083 Lines compiled, 0.8 sec C:\fpc\tests\webtbsfpc tw2242 -O2 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 tw2242.pp Linking tw2242.exe 13083 lines compiled, 4.7 sec , 301376 bytes code, 1864 bytes data Impressive. Now we can hook in. Where is the difference? What makes 2.4.0 so much slower? In the above case: primarily the register allocator (which I mentioned before). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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 ABI that maps classes, simple types, rtti, variables, methods, constructors, functions etc. to names the linker will then resolve... Since each symbol is only once included in the whole set of files that makes an application, I don't quite see the difficulty. Why is it that much different from a normal dll/so you link against? If you wanted to get RTTI for a particular type from a package, you could just manually call getProcAddress(mangled name) and use that pointer. Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 -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 Compiling tw2242.pp Linking tw2242.exe 13083 Lines compiled, 0.8 sec C:\fpc\tests\webtbsfpc tw2242 -O2 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 tw2242.pp Linking tw2242.exe 13083 lines compiled, 4.7 sec , 301376 bytes code, 1864 bytes data Impressive. Now we can hook in. Where is the difference? What makes 2.4.0 so much slower? 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 specifically tailored for i386. 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 like i386 as well as those with a lot registers: PowerPC) we support, so we need only to maintain one register allocator. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 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, getting file information and opening/closing files is another matter. The same with the fact that we use shortstring for performance in many places where delphi in fact allows longer mangled names and is faster. That's a non sequitur. - Possibily, a defaultly installed windows searches through a larger unit path (more dirs, more file) than Delphi _default_ I've also been thinking that. - Most profiling recently afaik has been done by Jonas, and thus not on Windows. Yet the delphi comparisons are on windows. There's a free profiler for Windows by AMD: http://developer.amd.com/cpu/codeanalyst/Pages/default.aspx Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 can compile so much faster and produces even better code? 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. If FPC does not fit into the CPU cache, then the CPU has to constantly load code mem additionally to the data. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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} directive must not have global variables, initialization sections,
or finalization sections. Which makes sense. So not putting something
into the bpl comes at a cost.
Also, I don't see the benefit of trying to introduce packages to have
each type defined only once within the project, except that all generic
types (and descendants thereof) would be spread all-over again.
So in short, everything in the units that doesn't go into the DLL goes into
the .DCP which is more or less a dcu archive if I understood it correctly
So only the specializations used inside the code contained in the BPL (and
maybe one or two that you could force to save duplication) are in the BPL.
So in short, the problem is one that you create yourself by self-inflicting
that every piece of code _must_ be in the BPL. That isn't the case.
Ok, so lets say one of my generic classes uses class variables (static
fields). Duplicating the type in each package defeats the purpose of the
package-concept to have one common type across all modules of a running
application.
Say I have a generic TMyListT type with some class variable. Then, I
use the specialization TMyListTMyOtherClass in two different packages
that depend on the package where TMyListT was defined. As soon as
TMyListT is put into the .dcp, it will be statically compiled into the
two other packages - hence you end up with 2 instances of the same
type, which leads to having 2 different versions of the class variable
(and N in the general case). In my opinion this is not what packages are
about. Packages are a means to transparently break your application in
to modules. BTW: It would be intersting to know whether Delphi allows
some sort of type TMyNewListT = type TMyListT definition which
would create a new type with a different set of class variables.
Finally, I have to confess that I am absolutely clueless about the
semantics of class variables in FPC's generics. Most probably FPC only
shares class variables between all instances of the same type mySpec =
specialization TMyList... type, which would give somewhat room for
the .dcp implementation. But this is not the usual semantics of
generics. It also is not the Delphi semantics of generics, I suppose.
This is (C++) templates without header files.
Cheers,
Willi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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 {$WEAKPACKAGEUNIT
ON} directive must not have global variables, initialization sections,
or finalization sections. Which makes sense. So not putting something
into the bpl comes at a cost.
No, it comes with limitations.
Also, I don't see the benefit of trying to introduce packages to have
each type defined only once within the project, except that all generic
types (and descendants thereof) would be spread all-over again.
That's where generics are special. The code is generated on the spot where
they are specialized, not on the spot where they are defined.
If you want to avoid that for space reasons, specialize a few common cases
in the BPL, or, if it is a system BPL, in a secondary BPL.
So in short, everything in the units that doesn't go into the DLL goes into
the .DCP which is more or less a dcu archive if I understood it correctly
So only the specializations used inside the code contained in the BPL (and
maybe one or two that you could force to save duplication) are in the BPL.
So in short, the problem is one that you create yourself by self-inflicting
that every piece of code _must_ be in the BPL. That isn't the case.
Ok, so lets say one of my generic classes uses class variables (static
fields). Duplicating the type in each package defeats the purpose of the
package-concept to have one common type across all modules of a running
application.
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 constraints to limit the definition to classes
implementing a certain interface, and it is said to typically share
specializations for such classes)
Say I have a generic TMyListT type with some class variable. Then, I
use the specialization TMyListTMyOtherClass in two different packages
that depend on the package where TMyListT was defined. As soon as
TMyListT is put into the .dcp, it will be statically compiled into the
two other packages - hence you end up with 2 instances of the same
type, which leads to having 2 different versions of the class variable
(and N in the general case).
Fully correct.
In my opinion this is not what packages are
about.
Well, what can I say about that?
Packages are a means to transparently break your application in
to modules.
True, the specialization is what generates the code AND THAT IS NOT IN THE
UNITS IN THE PACKAGE! So the logic still holds.
BTW: It would be intersting to know whether Delphi allows
some sort of type TMyNewListT = type TMyListT definition which
would create a new type with a different set of class variables.
You can try, but I doubt it. The = type x functionality is mostly
sleeping, in both FPC and Delphi.
Finally, I have to confess that I am absolutely clueless about the
semantics of class variables in FPC's generics. Most probably FPC only
shares class variables between all instances of the same type mySpec =
specialization TMyList... type,
That's what I expect yes.
which would give somewhat room for the .dcp implementation. But this is
not the usual semantics of generics. It also is not the Delphi semantics
of generics, I suppose. This is (C++) templates without header files.
As far as I know, it is this way for any compiled language.
The only exception I know is C#'s constraints, but that is possibly nothing
but a bit of damage control in a totally different environment. Still it
might be possible for FPC too, but that is a totally different subject.
When I read up about the C# stuff I didn't know that much about generics
yet, so if interested, I encourage you to do your own research. But don't
get your hopes up too much.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 the CPU cache, then the CPU has to constantly load code mem additionally to the data. - only the hot track has to fit. It makes no sense to cache processing parameter options. - all caches are afaik unified nowadays, so both code and data dynamically share the cache It could be that the working set is larger for FPC, but I doubt you can see this from the .exe size. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 like i386 as well as those with a lot registers: PowerPC) we support, so we need only to maintain one register allocator. I replaced the += by := s +, testresults on the same machine as before: Delphi 7: E:\FPC\svn\fixes_2_4\tests\webtbfdcc32 tw2242x.pp Borland Delphi Version 15.0 Copyright (c) 1983,2002 Borland Software Corporation tw2242x.pp(20009) 20010 lines, 0.19 seconds, 311088 bytes code, 1801 bytes data. E:\FPC\svn\fixes_2_4\tests\webtbf 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 too complex, it requires too many registers Fatal: Compilation aborted 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: E:\FPC\svn\fixes_2_4\tests\webtbfppc386 tw2242xtrunc.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 tw2242xtrunc.pp Linking tw2242xtrunc.exe 16381 lines compiled, 12.3 sec , 370736 bytes code, 1864 bytes data Hmm. ;-) Please take it with humor. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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: E:\FPC\svn\fixes_2_4\tests\webtbfppc386 tw2242xtrunc.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 tw2242xtrunc.pp Linking tw2242xtrunc.exe 16381 lines compiled, 12.3 sec , 370736 bytes code, 1864 bytes data Hmm. ;-) Please take it with humor. :-) 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. At the same time, this procedure compiles into a sequence of calls, which doesn't require registers at all (except to place function arguments). Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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, that's unrelated to SSA (or even graph colouring). Also, I think the limit is 65535 rather than 16384. Well, not entirely unrelated (more virtual registers are used with SSA), but even without SSA you run out of virtual registers after a while. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- 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, 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. that may be the case for reading, not necessarily for the files being written. in ppu.pas, everything you put results in a blockwrite of x bytes. Wouldn't a cached memory stream be better, not resulting in those int21h calls or windows equivalent calls? Haven't looked at .s creation (donno where to start looking, but I guess this is the same???) The same with the fact that we use shortstring for performance in many places where delphi in fact allows longer mangled names and is faster. That leaves the maintainability bit. I think that is certainly true, and it probably can be tweaked to be a bit better. It won't be easy though and is more likely to be a lot of things that add a little than few that matter a lot. Which makes it a permanent positions instead of a one-off effort. Any takers? As far as the I/O performance discussion goes, some observations: - To find something interesting, probably the test has to be done for various sizes of code. To see if maybe some startup factor (Rather than actual processing) is a cause. agreed - FPC has to read at least twice the number of files (.ppu/.o). So if opening or number of files in the dir path is a factor, it will do worse by default. actually, this is a false statement. The units that come with delphi (rtl and others) are packaged in .dcp (and .bpl). That means that not only those x2 files, but a factor of those x2 can be done. Admitted that you probably load way to much in some cases as well as that it is not easy to know in what .dcp your needed unitinfo is included. Or at least isn't obvious. - Possibily, a defaultly installed windows searches through a larger unit path (more dirs, more file) than Delphi _default_ - For that to be found, more has to be known about dcc.cfg during the tests. - THis means that tests will have to be repeated with various sizes of unitpath trees (both dirs and files) to see if this is a discussion. - Most profiling recently afaik has been done by Jonas, and thus not on Windows. Yet the delphi comparisons are on windows. - Actually linking should be avoided in the test. It might obscure things. in that case, all external tools should be avoided. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 conflicting statements: 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. that may be the case for reading, not necessarily for the files being written. in ppu.pas, everything you put results in a blockwrite of x bytes. Wouldn't a cached memory stream be better, not resulting in those int21h calls or windows equivalent calls? The ppu writer uses a buffer of 16 kB which is enough. Believe me, it's no so simple as just use a memory stream to improve performance. If it's the case, we would have done it for years. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 too complex, it requires too many registers This could be fixed for another speed penalty :) Please take it with humor. :-) As long as the compiler itself builds on a reasonable machine in less than 10 seconds, I'am happy :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 people who have no reasonable machine. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 blockwrite of x bytes. Wouldn't a cached memory stream be better, not resulting in those int21h calls or windows equivalent calls? Haven't looked at .s creation (donno where to start looking, but I guess this is the same???) It's worth checking out. (writing in general), but I don't expect the difference to be shocking. If only because typically many more .ppu are read than written. - FPC has to read at least twice the number of files (.ppu/.o). So if opening or number of files in the dir path is a factor, it will do worse by default. actually, this is a false statement. The units that come with delphi (rtl and others) are packaged in .dcp (and .bpl). That means that not only those x2 files, but a factor of those x2 can be done. Admitted that you probably load way to much in some cases as well as that it is not easy to know in what .dcp your needed unitinfo is included. Or at least isn't obvious. To my best knowledge that is incorrect. Delphi uses the .dcu's (debug or not), and only preloads the .dcp that are in the runtime packages list when compiling with packages is checked. of unitpath trees (both dirs and files) to see if this is a discussion. - Most profiling recently afaik has been done by Jonas, and thus not on Windows. Yet the delphi comparisons are on windows. - Actually linking should be avoided in the test. It might obscure things. in that case, all external tools should be avoided. For benchmarking: yes. It would actualy be interesting to learn such info, since generally I've only regarded command like make all in the past. There, Windows (time) : linux (time) is about 2:1, but I always blamed the bulk on this on the slower startup time of windows exes. Such benchmarks could confirm (or dispell) that assumption. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 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, getting file information and opening/closing files is another matter. Good. That's what I wanted to say too. If one excludes linking, there is not that much left. I assume the moments of timing of the FPC and Delphi compiler of course could be different too. The same with the fact that we use shortstring for performance in many places where delphi in fact allows longer mangled names and is faster. That's a non sequitur. I'm not creating a complot theory here. I just want to state some facts to avoid sidediscussion obscuring the main problem. I'm not expecting sb will go really deep and profiling, but that doesn't mean a somewhat correct definition of the cause of the difference would hurt. If only for the next discussion. - Most profiling recently afaik has been done by Jonas, and thus not on Windows. Yet the delphi comparisons are on windows. There's a free profiler for Windows by AMD: http://developer.amd.com/cpu/codeanalyst/Pages/default.aspx I'll see if I can make/enhance the wiki page about profiling the coming days. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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, getting file information and opening/closing files is another matter. My exeperience seems to confirm this. I ran the same tests with Lazarus install on a NAS. As the connection was 2xGigabit (port-trunked), read/write speeds were higher than my local HHD. Yet, rebuild times doubled. It seems latency plays a more significant role than thoughput. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 --running in the background as I write. But, do you know if it takes into account processes (exe's) started by the process (exe) being profiled? Also, does anyone know if Intel's vTune would be useful? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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-us/performance/cc825801.aspx It's a 2.5G download --running in the background as I write. But, do you know if it takes into account processes (exe's) started by the process (exe) being profiled? I know next to nothing about Windows development since I don't use Windows. I just googled for profiling windows and followed the links from the first result I got (http://stackoverflow.com/questions/67554/whats-the-best-free-c-profiler-for-windows-if-there-are). Besides, FPC on Windows does not start any other executables when compiling programs. And note that even with a profiler you have to know what you should measure, what is relevant and what the results mean before you can draw any conclusions (just like with the disk benchmarking you did). If you don't know anything about that, read the manual/docs. For example, the profiling results I posted earlier to this list do not say anything about the influence of I/O since they were based on sampling the program code executing every 1 millisecond. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- 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 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: maybe it fits into the cpu cache. I assume dcc.exe uses more data than code :-) 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 + more .dll's help? aka a compiler package, a rtl, a assembler package, ...? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 for other tasks than compiling FPC and there are people who have no reasonable machine. ;-) Those can always use FPC 1.x or Delphi7 :) There is no free lunch ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 into .exe + more .dll's help? Only the parts of the executable that are actually used (plus some surrounding bytes) are loaded into the caches. Splitting the used (or unused) code will not change that. You might want to read up on cpu caches: http://en.wikipedia.org/wiki/CPU_cache#Details_of_operation Furthermore, splitting everything will make things worse, because then you get extra glue code and/or dynamic linker fix ups (i.e., it increases the code size and the program execution time). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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: 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: maybe it fits into the cpu cache. I assume dcc.exe uses more data than code :-) 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 + more .dll's help? aka a compiler package, a rtl, a assembler package, ...? No. Putting code into dll/so can even create slower code. The cpu cache uses cache lines, so only the relevant parts of the machine code is loaded, no matter if it is in a dll, exe, so or whatever. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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 constraints to limit the definition to classes implementing a certain interface, and it is said to typically share specializations for such classes) 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. However, Delphi won't allow you to do something like TMyGenericBaseClassT = class public public function AddOp(a: T; b: T) : T; end; implementation function TMyGenericBaseClassT.AddOp; begin result := a + b; end; since the '+' operator is not defined on T. Delphi lets you constrain your type parameters. That said, I don't really understand why constraints like :integer, :TObject are not allowed. (:record, :TMyClass are perfectly fine.) So Delphi's generics are more on the C#/.NET side than on the C++ template side. Packages are a means to transparently break your application in to modules. True, the specialization is what generates the code AND THAT IS NOT IN THE UNITS IN THE PACKAGE! So the logic still holds. Uh, no need to shout. I understand what you are saying, however, I'd still prefer to have working class variables, rtti checks etc. even with generic classes and packages. BTW: It would be intersting to know whether Delphi allows some sort of type TMyNewListT = type TMyListT definition which would create a new type with a different set of class variables. You can try, but I doubt it. The = type x functionality is mostly sleeping, in both FPC and Delphi. Tried it: not allowed. The only exception I know is C#'s constraints, but that is possibly nothing but a bit of damage control in a totally different environment. Still it might be possible for FPC too, but that is a totally different subject. Well, IIRC Eiffel, Java/Pizza, .NET, Delphi all support constraints on type parameters. .NET actually has quite good support for generics (Java is limited in that respect). When I read up about the C# stuff I didn't know that much about generics yet, so if interested, I encourage you to do your own research. But don't get your hopes up too much. Ok for the start I'll be looking at co/contravariance, and lambda functions ;-). Joke aside, I'll think about the .dcp idea and how this might work out with packages. Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with makefiles, fpcmake, Package.fpc and fppkg
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. Normally not really a problem, but fppkg uses these files to resolve dependencies. But the dependencies of the sub-package could be different from the dependencies of the main package. Example: when you do 'make install' in fcl-web, a Package.fpc will be installed without the dependency on fcl-db. (In fact a Package.fpc made for jsonrpc is installed, which doesn't depend on fcl-db) The result is that if you have fcl-web installed using fpcmake, and you want to install some other package using fpmake that depends on fcl-web, that will fail. Shall I submit a bug-report for fpcmake with a request to use the proper Package.fpc file? Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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 classes) 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 already more than I expected. since the '+' operator is not defined on T. Generic versions of Delphi have operator overloading? Or did I miss something here? Delphi lets you constrain your type parameters. That said, I don't really understand why constraints like :integer, :TObject are not allowed. Does C# actually allow that? I thought it only supported interfaces? (:record, :TMyClass are perfectly fine.) So Delphi's generics are more on the C#/.NET side than on the C++ template side. Well, when they were developed, Delphi.NET was just being canceled, so that is no suprise. Uh, no need to shout. I understand what you are saying, however, I'd still prefer to have working class variables, Personally I only am interested in the constraint for object types. Many generic container types operating on objects only improve typing, and thus are runtime empty. Mapping them onto eachother makes .exe's and memory footprint smaller, and more importantly, might have an effect on caches. The opposite constraint (that excludes inheritable types) could maybe be useful for optimizations. rtti checks etc. even with generic classes and packages. You'll have to explain that in more detail. I fail to see the connection. Moreover, this is turning into a generics feature and wishlist discussion, while it was about packages. You can try, but I doubt it. The = type x functionality is mostly sleeping, in both FPC and Delphi. Tried it: not allowed. No surprise there. The only exception I know is C#'s constraints, but that is possibly nothing but a bit of damage control in a totally different environment. Still it might be possible for FPC too, but that is a totally different subject. Well, IIRC Eiffel, Java/Pizza, .NET, Delphi all support constraints on type parameters. .NET actually has quite good support for generics (Java is limited in that respect). Java and .NET also is a JIT who can delay certain things till runtime, when all loaded parts form a single program over which the JIT has more or less a complete overview. IMHO interesting for ideas, but not for implementation. Delphi has constraints, but they don't reach your goals. So maybe it is time to stop the comparison game, and describe how you think such features should work. Ok for the start I'll be looking at co/contravariance, and lambda functions ;-). Joke aside, I'll think about the .dcp idea and how this might work out with packages. Note that .bpl : a DLL with some runtime stuff. .dcp : everything else, - the .ppu like information for everything in .BPL (since the .bpl/.exe split is arbitrary, the compiler has full control, so it must be in there) - code that didn't go into the .bpl (weakpackaged, maybe even complete units, but also stuff to construct tables needed in the main program) - everything not linkable, inline functions, generics etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 called are below [numbers represent 'events']. ppcx64.exe: 274,889 make.exe: 27,664 rm.exe: 17,968 fpc.exe: 8,992 gorc.exe: 6,718 lazarus.exe: 6,593 conhost.exe: 4,751 gdate.exe: 3,122 pwd.exe: 1,483 startlazarus.exe: 1,092 cmd.exe: 786 csrss.exe: 642 here, for example, the 'events' for make.exe: QueryDirectory: 6,502 CreateFile: 5,800 CloseFile: 4,916 CreateFileMapping: 1,591 RegOpenKey: 1,483 QueryNameInformationFile: 727 QueryOpen: 675 RegCloseKey: 643 RegQueryValue: 591 QueryBasicInformationFile: 554 RegSetInfoKey: 552 ReadFile: 511 Load Image: 431 QueryStandardInformationFile: 367 RegQueryKey: 341 QueryFileInternalInformationFile: 318 SetBasicInformationFile: 318 QueryInformationVolume: 288 QueryAttributeInformationVolume: 276 QuerySecurityFile: 228 QueryAttributeTagFile: 205 FileSystemControl: 126 Process Create: 113 RegEnumKey: 26 RegEnumValue: 26 Process Exit: 13 Process Start: 13 Thread Create: 13 Thread Exit: 13 WriteFile: 2 SetDispositionInformationFile: 1 SetEndOfFileInformationFile: 1 I am not sure what all those do, but 'Load Image: 431' seems to mean 'make.exe' is run 431 times. And note that even with a profiler you have to know what you should measure, what is relevant and what the results mean before you can draw any conclusions (just like with the disk benchmarking you did). If you don't know anything about that, read the manual/docs. For example, the profiling results I posted earlier to this list do not say anything about the influence of I/O since they were based on sampling the program code executing every 1 millisecond. ATM, I am mainly interested in finding out how many other external process Lazarus depends on (how many times does it call them) when compiling/building an exe. For that, a process explorer should be sufficient. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
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 already more than I expected. Well, half working is still broken. :-\ Better not supported than half working, if you ask me. BTW: I've read somewhere on the internet (don't know whether that's true) that C# supports static fields in a proper way: Even if there is only one code-path for all object-related types, static fields are different for each different instantiated type. Hence StackTObject would have different static fields than any object based on StackderivedFromObject. since the '+' operator is not defined on T. Generic versions of Delphi have operator overloading? Or did I miss something here? Sorry, my bad. Compiler says not applicable. Delphi lets you constrain your type parameters. That said, I don't really understand why constraints like :integer, :TObject are not allowed. Does C# actually allow that? I thought it only supported interfaces? Well, you can use 'struct' (record in delphi), class, new (IIRC constructor in delphi), some base class, or some interface name, or some other generic parameter as constraint. Pretty much the same as in Delphi. Personally I only am interested in the constraint for object types. Many generic container types operating on objects only improve typing, and thus are runtime empty. Mapping them onto eachother makes .exe's and memory footprint smaller, and more importantly, might have an effect on caches. And would need only one implementation in a package. ;-) That said, there'd be still the need for different RTTI entries for different instantiations... The opposite constraint (that excludes inheritable types) could maybe be useful for optimizations. rtti checks etc. even with generic classes and packages. You'll have to explain that in more detail. I fail to see the connection. I don't know whether it is still the case but there was a time the 'is' operator relied on RTTI. So as soon as you have two different RTTI entries for, e.g., TMyListinteger (which could happen if you compile with packages) the operator needs some 'repair'. I don't know how Delphi handles this today and whether to repair it is a good idea. This, btw, was one of the downsides that made MDI-Child-Form-plugins via dlls back in D5/6 days quite difficult: even if the object was, say, a form, the 'is' operator failed. I'd need to look into the FPC sources to see how FPC handles this situation. Moreover, this is turning into a generics feature and wishlist discussion, while it was about packages. Well, it's related. Since generics have to be supported by packages, it's necessary to discuss the approaches. What must not happen is that a program behaves differently when compiled with packages because of the way things are done. Java and .NET also is a JIT who can delay certain things till runtime, when all loaded parts form a single program over which the JIT has more or less a complete overview. IMHO interesting for ideas, but not for implementation. True, a JIT has additional runtime knowledge an will only construct the types that are really necessary. Delphi has constraints, but they don't reach your goals. So maybe it is time to stop the comparison game, and describe how you think such features should work. Well, actually Delphi generics come really close. AFAICT generics in Delphi work the way I described them in one of my first emails about the subject: Within the generic type you can only do operations on the generic value that you know (from the constraint) are allowed. So you can compile (syntax check) the generic type separately from the code that uses it. This would in turn be beneficial for packages, as, e.g., for object types you could use one common code path. When using primitive types, code needs to end up in the dcp, yes, but perhaps there is a way so that RTTI is shared? (And class vars are working.) That said, if there is no sane way for class vars working on generic types, I'd rather give them up (for these types). Cheers, Willi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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, here the list executables of executables called are below [numbers represent 'events']. That's indeed not FPC starting executables, that's Lazarus invoking make (which in turn invokes tons of other stuff). I am not sure what all those do, but 'Load Image: 431' seems to mean 'make.exe' is run 431 times. make indeed works by recursively executing itself. And that is a known problem on Windows, because that platform is extremely slow at starting new processes for some reason. Some people have worked on alternatives (http://fastmake.org/, http://benjamin.smedbergs.us/pymake/), but afaik none of them can currently deal with everything that appears in FPC's makefiles. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
