Re: [fpc-devel] FPC/Lazarus Rebuild performance
On Friday 10 September 2010 17:43:59 Adem wrote: Sometime ago, there was a brief mention of multi-threading FPC would be counter productive because compilation process was mostly disk IO bound --this is what I understood anyway. I wanted to check to see if disk IO was really limiting FPC/Lazarus compile performance. Interesting is that Delphi 7 compiles about 10 times faster than FPC on the same machine. http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html Results with more code and FPC 2.4: http://thread.gmane.org/gmane.comp.ide.mseide.user/18797 One would think Delphi and FPC need the same disk IO? 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 11 Sep 2010, at 08:55, Martin Schreiber wrote: Interesting is that Delphi 7 compiles about 10 times faster than FPC on the same machine. http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html Results with more code and FPC 2.4: http://thread.gmane.org/gmane.comp.ide.mseide.user/18797 One would think Delphi and FPC need the same disk IO? First of all, they don't, unless Delphi's source/DCU searching and DCU loading logic is identical to FPC's. Secondly, even *if* FPC (due to its design) is currently mainly limited in speed by I/O and *if* parellising would not help much because of that reason, then it can still also be slower than Delphi in other ways. Since Delphi 7 does not use parallel compilation (afaik), that's in fact a given. So yes, FPC is slower than Delphi. Would parallelising FPC reduce the speed gap? Maybe (more likely for hot compiles), maybe not (more likely for cold compiles). 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 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 calculation. - Delphi is much faster than FPC. - Delphi uses a file access approach which performs much better than the approach of FPC. or it isn't true that FPC bottleneck is disk IO. Are we absolutely sure about the bottleneck? 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 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. I wanted to check to see if disk IO was really limiting FPC/Lazarus compile performance. Interesting is that Delphi 7 compiles about 10 times faster than FPC on the same machine. http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html Results with more code and FPC 2.4: http://thread.gmane.org/gmane.comp.ide.mseide.user/18797 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. Also starting a new process is slow. These OS kernel tasks are difficult to measure and process monitors don't give reliable results. Suggestion: Create an API for integrating FPC with IDEs and special make programs. The API would pass info about exact file names and locations. It could also pass the whole source memory buffers. Then build FPC as a dynamic shared library. There would be 2 FPC binaries then: the traditional executable, and a shared library to be called from external programs. For example Lazarus IDE already scans a lot of information about project's files and directories. That info could be easily passed to compiler. Codetools in Lazarus already parses lots of code. The whole parsed interface section could be passed to compiler (symbol table and whatnot). ... but that is the next step, let's stick with file info now... Then there would be a new dedicated build program which reads all project info first and then calls the compile function (not a separate process) in the shared lib for each source file. No expensive process startups, no searching for include files again for each source file from huge directory structures. I bet it would make a BIG difference in speed. Delphi must be doing something like this although I don't know details. After that it makes sense to make the compiler multi-threaded. It could scale almost linearly with CPU cores (maybe). I haven't seen such ideas in these mailing lists. Is it possible I am the first one to have it? I don't believe because the idea is so obvious. If there is already such development with the new make tools then sorry for my ignorance. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 platform and from compilation scenario to compilation scenario. I'm quite sure there is not a single thing you can fix and suddenly get compilation speeds in the same ballpark as Delphi 7 (how does the compilation speed of current Delphi's compare to Delphi 7 btw? I read that Delphi XE compiles much faster than Delphi 2010 in some cases, but I did not see comparisons to Delphi 7). One thing that could be done is adding a linear scan register allocator (it would result in slightly worse code than the current register colouring, but it executes more quickly). Going further, general restructuring of the compiler for compilation speed reasons would only be acceptable if it does not negatively impact the maintainability. There is a reason why we can support 6 architectures and umpteen OSes in the compiler with only a handful of people. 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 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. Also starting a new process is slow. These OS kernel tasks are difficult to measure and process monitors don't give reliable results. Suggestion: Create an API for integrating FPC with IDEs and special make programs. The API would pass info about exact file names and locations. It could also pass the whole source memory buffers. And why does the Delphi commandline compiler (dcc32) not need this IDE assistance? 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 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 external process then it can use some (hidden) temporary file with pre-scanned info of the project. So the compiler would only open one info file instead of scanning the whole search paths. I used the IDE always when working with Delphi and don't really know dcc32. Guessing only. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 platform to platform and from compilation scenario to compilation scenario. I'm quite sure there is not a single thing you can fix and suddenly get compilation speeds in the same ballpark as Delphi 7 (how does the compilation speed of current Delphi's compare to Delphi 7 btw? I read that Delphi XE compiles much faster than Delphi 2010 in some cases, but I did not see comparisons to Delphi 7). One thing that could be done is adding a linear scan register allocator (it would result in slightly worse code than the current register colouring, but it executes more quickly). Going further, general restructuring of the compiler for compilation speed reasons would only be acceptable if it does not negatively impact the maintainability. There is a reason why we can support 6 architectures and umpteen OSes in the compiler with only a handful of people. One idea that comes at this point is to put PPU data directly into object files, so the number of output files is reduced plain twice. The PPU data could be placed into a section that is ignored by linker. However I don't know is this is possible for all platforms. 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 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 external processes for each file. No it does not. dcc32 compiles 1 file only, but does compile any additional units it needs. You'll need makefiles as well if you use dcc32 (or any other build tool). I have an extended build system using dcc32, and it takes easily up to 15 minutes to compile a 1.5 million lines project. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 Delphi. The bottlenecks probably also vary from platform to platform and from compilation scenario to compilation scenario. I'm quite sure there is not a single thing you can fix and suddenly get compilation speeds in the same ballpark as Delphi 7 (how does the compilation speed of current Delphi's compare to Delphi 7 btw? I read that Delphi XE compiles much faster than Delphi 2010 in some cases, but I did not see comparisons to Delphi 7). One thing that could be done is adding a linear scan register allocator (it would result in slightly worse code than the current register colouring, but it executes more quickly). Going further, general restructuring of the compiler for compilation speed reasons would only be acceptable if it does not negatively impact the maintainability. There is a reason why we can support 6 architectures and umpteen OSes in the compiler with only a handful of people. One idea that comes at this point is to put PPU data directly into object files, so the number of output files is reduced plain twice. The PPU data could be placed into a section that is ignored by linker. However I don't know is this is possible for all platforms. Not each platform may support this, so if you want to go down this path, why not do the opposite, as Delphi ? Putting the .o data at the end allows the compiler to simply not read that data when reading the PPU. Only when actually linking do you need to extract all .o data from the ppus. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 assistance? My guess is that dcc32 works as an integrated make program + compiler and thus doesn't start external processes for each file. No it does not. dcc32 compiles 1 file only, but does compile any additional units it needs. You'll need makefiles as well if you use dcc32 (or any other build tool). I have an extended build system using dcc32, and it takes easily up to 15 minutes to compile a 1.5 million lines project. Maybe dcc32 likes the MSEgui sources. Martin, can you give a comparison between win32 and Linux 32? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
Michael Van Canneyt пишет: One idea that comes at this point is to put PPU data directly into object files, so the number of output files is reduced plain twice. The PPU data could be placed into a section that is ignored by linker. However I don't know is this is possible for all platforms. Not each platform may support this, so if you want to go down this path, why not do the opposite, as Delphi ? Putting the .o data at the end allows the compiler to simply not read that data when reading the PPU. Only when actually linking do you need to extract all .o data from the ppus. That is an option, too. But given that linking typically takes place at every build (as opposed to compiling), I am afraid that total number of file operations on platforms without builtin linker won't be noticeably less than it is currently. 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 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 that Kylix 3 is supposed to be on-par with Delphi 7. I've got Kylix 3 Enterprise running in a VM here, I also have Delphi 7 available in a VM. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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? In theory yes, I did not test recently. Probably some modifications in Linux MSEgui are necessary now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 and Windows had about the same compiling performance. Building MSEide with FPC fixes_2_4, about 366'000 lines: Windows NTFS: smartlink 50.4 sec no smartlink 50.5 sec Same machine Linux reiser FS: smartlink 126 sec no smartlink 62.7 sec. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 3 environment at the moment. IIRC dcc32 on Linux and Windows had about the same compiling performance. Building MSEide with FPC fixes_2_4, about 366'000 lines: Windows NTFS: smartlink 50.4 sec no smartlink 50.5 sec What machine? Because with hot disk cache, I just build MSEide in about 10 s (15 s cold) on W7 64 Bit: ... Linking mseidefp.exe 308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data 196 warning(s) issued 414 note(s) issued ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 32? I don't have a working Kylix 3 environment at the moment. IIRC dcc32 on Linux and Windows had about the same compiling performance. Building MSEide with FPC fixes_2_4, about 366'000 lines: Windows NTFS: smartlink 50.4 sec no smartlink 50.5 sec Same machine Linux reiser FS: smartlink 126 sec no smartlink 62.7 sec. Strange. Here fpc is much faster, even on a 3 year old linux machine: 343520 lines compiled, 16.2 sec 258 warning(s) issued 570 note(s) issued real0m16.249s user0m14.953s sys 0m0.904s time /usr/lib/fpc/2.4.0/ppc386 -omseide -Fu...msegui/lib/addon/*/ -Fi...msegui/lib/addon/*/ -Fu...msegui/lib/common/kernel/i386-linux/ -Fu...msegui/lib/common/kernel/ -Fi...msegui/lib/common/kernel/ -Fu...msegui/lib/common/*/ -l -Mobjfpc -Sh -gl -O- mseide.pas Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 sec , 2577952 bytes code, 1618920 bytes data Then Delphi7 probably uses about 1 sec on your 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
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 ... Linking mseidefp.exe 308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data Then Delphi7 probably uses about 1 sec on your machine. ;-) ... mseide.pas(63) 280491 lines, 2.18 seconds, 2110568 bytes code, 752073 bytes data. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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 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. Note that in 2.5.1 it will already be somewhat faster because of r15604 (removes a lot of calls to fillchar from the register allocator) and r15515 (optimizations to sysfreemem_fixed). True, but at least I fear the generic i386 fillchar is slower than the MacOSX system routine __bzero. But I agree also that there won't be a big improvement by improving fillchar. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
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? 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? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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 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 directory structures. It is slow even if the files are cached. Also starting a new process is slow. These OS kernel tasks are difficult to measure and process monitors don't give reliable results. Suggestion: Create an API for integrating FPC with IDEs and special make programs. The API would pass info about exact file names and locations. It could also pass the whole source memory buffers. 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). Juha's idea is the way Borland did it with D7. That is: a shared lib with api a commandline tool. Unfortunately the DLL is not linked from the cmdline tool, so it seems those 2 are separately compiled and statically linked with 'the same' code. Donno for sure if that still is the case with 2010/XE. 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
- 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 thus doesn't start external processes for each file. Or, if it starts an external process then it can use some (hidden) temporary file with pre-scanned info of the project. So the compiler would only open one info file instead of scanning the whole search paths. I used the IDE always when working with Delphi and don't really know dcc32. Guessing only. no, the bin directory of D7 is filled with extra .exe's (tlib, tasm32, ...) and the dcc32.exe is 800K big. 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
- 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 as an integrated make program + compiler and thus doesn't start external processes for each file. No it does not. dcc32 compiles 1 file only, but does compile any additional units it needs. You'll need makefiles as well if you use dcc32 (or any other build tool). I have an extended build system using dcc32, and it takes easily up to 15 minutes to compile a 1.5 million lines project. that is my experience as well. (using 'want.exe' aka windows 'ant') it implies though that you can merely compile your .dpk and .dpr files to get everything compiled ;-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Packages, Generics
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. However, since FPC supports more then the simple D6 language, I had a look at generics in particular. First, let me say that I am really glad to see this feature in FPC. However, I have to say that generics are NOT equivalent to C++ templates and should not be. (I strongly dislike the specialize keyword, btw., even though it makes the process of 'instantiating' the 'template' more apparent.) So, generics are _not_ pre-processor style macros - generic types are proper types. Let me explain. Normally, a generic type can be statically checked by the compiler on it's own. You do not need to specialize it. The reason is simple: for most of the time, you could think of a generic type parameter as a variable with the type 'class of X' (which Pascal already supports). With the content of this variable you can do everything that is described in the public interface of its type. Nothing more, nothing less. For generic classes, this means that the compiler is able to check 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. Thereby 'all possible instantiations' means one for each non-oo type and at least one for all the object types (and possible combinations). Still worse, this would even break the 'one-implementation for all classes thing', because different classes could provide a method with the same name... (which would end up at different places in memory). I don't know how Delphi solves these issues (w. regards to packages) but I think the one way to deal with this is to restrict the operations that can be done with values of generic types so that these operations match the type-information of the generic type parameters (e.g., generic A = class T1 :Ordinal... ...). As said, all the class/interface types are no problem - they probably just need one specialization. Primitive types are basically grouped in Ordinals, Reals, Characters, Structures, Pointers, Functions. Each group comes with a set of operations that is valid and quite a lot of them end up being passed around as pointers. Refcounting aside, a common operation allowed on all types would be the assignment. This is enough for simple generic containers. Hence, if no other operation is needed, one common specialization could do. (Refcounting issue would still need to be solved, though.) If the developer needs more advanced operations, he/she has to narrow down the type that is allowed for specialization: Oridnal, or Real, or some TMyClass... . You get the basic idea. The more one restricts the generic parameter, the more one is allowed to do with values of that type. Which is the big difference to C++ templates, and the way generics should work. 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. 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
- 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 all other tests, win2000, AMD Athlon XP 3000+, 1GB RAM ... Linking mseidefp.exe 308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data Then Delphi7 probably uses about 1 sec on your machine. ;-) ... mseide.pas(63) 280491 lines, 2.18 seconds, 2110568 bytes code, 752073 bytes data. 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. I am not as intimately familiar with the compiler internals as most of you, but the writing/reading of those .ppu files looks to me like a prime candidate. other things that I do not know if they are already implemented this way: 1) if the .ppu/.ppl + .o are merged and they give better results then why not go the extra mile and implement packages (or at least the .dcp)? Although I fail to see why (except for linking) both have to be opened during compilation. With packages I mean the .dcp/.bpl equivalent. It is my understanding that .dcp is like a .lib + all the stuff in the unitinfo (.dcu / .ppu), and ofcourse the more simpler .bpl = .dll with extra's. That way, you need to dive into much less files. 2) when fetching / checking the files, does it happen according to the unit include paths and those paths appended by targetos en architectures for every file? Wouldn't it be more efficient to fetch/cache some dir-info first for all files in those dirs and then fetch the necessary info from there? For instance: get filenames + size + timestamp for all .ppu files or .pas files first. 3) It is my understanding that the .ppu structures are written with size-footprint in mind, not processing efficiency? Maybe the structures need changing too? 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
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). The comparisons I made were with dcc32 not Delphi IDE. The commands are here: http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg08029.html 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 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? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
