Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
2013/3/8 Graeme Geldenhuys : > Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 > lines for the actual message. Keep up the good work. Good quoting, it just read that message and got a comprehensive story, especially because my autofilter deletes mails from Michael Schnelll. > > Netiquette? Spoilt by gmail. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 08.03.2013 00:43 schrieb "Graeme Geldenhuys" : > > Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 > lines for the actual message. Keep up the good work. > > Netiquette? This should have been shortened indeed... To my defense: I wanted to get this mail out, fix another problem (see fpc-pascal list) and hop into bed... You should also take into consideration that I normally *do* shorten my mails. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work. Netiquette? G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 06.03.2013 14:36, Sven Barth wrote: Am 06.03.2013 14:29, schrieb Michael Schnell: On 03/06/2013 01:43 PM, Sven Barth wrote: And how does one the "current" TThread? Since a few weeks: TThread.CurrentThread ;) This does in fact use a threadvar: threadvar { the instance of the current thread; in case of an external thread this is Nil until TThread.GetCurrentThread was called once (the RTLs need to ensure that threadvars are initialized with 0!) } CurrentThreadVar: TThread; and (unless the compiler optimizes this out) even accesses it twice: if not Assigned(CurrentThreadVar) then CurrentThreadVar := TExternalThread.Create; Result := CurrentThreadVar; From within the TThread object, simply using Self seems more appropriate unless there is a chance that the same TThread instance is used for multiple OS-Threads. I don't know if/how this is possible. From "outside" I feel that AnyThread.GetCurrentThread does not make much senses. When doing "TThread.GetCurrentThread" as a class function I think I should get "self" of same when I am in the code that is called from "Execute" of some TThread instance. I don't see what I want to see when I'm not. The code seems to try to avoid the case that a no TThread instance when GetCurrentThread is called as a a class function. I don't know if/how this is sensible. Using CurrentThread only seems sensible within the the code of a component that has been called by the code of a TThread instance. But here using an appropriate back-link property can easily be used to avoid accessing the threadvar. (or using CurrentThread once to set a property and then just accessing same.) But this of course needs to be done in user code and the RTL can't force it. The TThread.CurrentThread is mainly for access in functions that don't get passed a "TThread" instance and to also get a "TThread" instance for threads not created by the RTL (the "TExternalThread.Create" line above). Don't forget that TThread.CurrentThread is a class property/function, so you can't access Self. We could optimize it like this: === code begin === Result := CurrentThreadVar; if not Assigned(Result) then begin Result := TExternalThread.Create; CurrentThreadVar := Result; end; === code end === So that in the normal case only one access to the threadvar is used. I've implemented this optimization in r23706. So in the normal case the threadvar is only read once and in the worst case it's read once and written once. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
time make -j 64 == It might not build modules - which present a lot of files thsu I/O. "make -j .. deb-pkg" builds & packs both image & modules (the benchmark has selected for build approx 75% of all available modules ) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
make -j has a dramatic effect on an SMP system, particularly if it can find groups of jobs without too much interdependence. = The benchamark was surprising. Diring it, me observed 80..95% load of each CPU still having high I/O load on the RAID1. How can it be ?! Which were the CPUs engaged for ? Me guess because of the design flaw of Core-I* arch where proper (disk/network- to-from-RAM leaving CPUs idle from I/O) DMA transfers are impossible since the RAM can only be accessed via CPUs so CPUs has to serve each smallest I/O operation. Really very strange. The kernel is customized, sure :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 06.03.2013 14:29, schrieb Michael Schnell: On 03/06/2013 01:43 PM, Sven Barth wrote: And how does one the "current" TThread? Since a few weeks: TThread.CurrentThread ;) This does in fact use a threadvar: threadvar { the instance of the current thread; in case of an external thread this is Nil until TThread.GetCurrentThread was called once (the RTLs need to ensure that threadvars are initialized with 0!) } CurrentThreadVar: TThread; and (unless the compiler optimizes this out) even accesses it twice: if not Assigned(CurrentThreadVar) then CurrentThreadVar := TExternalThread.Create; Result := CurrentThreadVar; From within the TThread object, simply using Self seems more appropriate unless there is a chance that the same TThread instance is used for multiple OS-Threads. I don't know if/how this is possible. From "outside" I feel that AnyThread.GetCurrentThread does not make much senses. When doing "TThread.GetCurrentThread" as a class function I think I should get "self" of same when I am in the code that is called from "Execute" of some TThread instance. I don't see what I want to see when I'm not. The code seems to try to avoid the case that a no TThread instance when GetCurrentThread is called as a a class function. I don't know if/how this is sensible. Using CurrentThread only seems sensible within the the code of a component that has been called by the code of a TThread instance. But here using an appropriate back-link property can easily be used to avoid accessing the threadvar. (or using CurrentThread once to set a property and then just accessing same.) But this of course needs to be done in user code and the RTL can't force it. The TThread.CurrentThread is mainly for access in functions that don't get passed a "TThread" instance and to also get a "TThread" instance for threads not created by the RTL (the "TExternalThread.Create" line above). Don't forget that TThread.CurrentThread is a class property/function, so you can't access Self. We could optimize it like this: === code begin === Result := CurrentThreadVar; if not Assigned(Result) then begin Result := TExternalThread.Create; CurrentThreadVar := Result; end; === code end === So that in the normal case only one access to the threadvar is used. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/06/2013 01:43 PM, Sven Barth wrote: And how does one the "current" TThread? Since a few weeks: TThread.CurrentThread ;) This does in fact use a threadvar: threadvar { the instance of the current thread; in case of an external thread this is Nil until TThread.GetCurrentThread was called once (the RTLs need to ensure that threadvars are initialized with 0!) } CurrentThreadVar: TThread; and (unless the compiler optimizes this out) even accesses it twice: if not Assigned(CurrentThreadVar) then CurrentThreadVar := TExternalThread.Create; Result := CurrentThreadVar; From within the TThread object, simply using Self seems more appropriate unless there is a chance that the same TThread instance is used for multiple OS-Threads. I don't know if/how this is possible. From "outside" I feel that AnyThread.GetCurrentThread does not make much senses. When doing "TThread.GetCurrentThread" as a class function I think I should get "self" of same when I am in the code that is called from "Execute" of some TThread instance. I don't see what I want to see when I'm not. The code seems to try to avoid the case that a no TThread instance when GetCurrentThread is called as a a class function. I don't know if/how this is sensible. Using CurrentThread only seems sensible within the the code of a component that has been called by the code of a TThread instance. But here using an appropriate back-link property can easily be used to avoid accessing the threadvar. (or using CurrentThread once to set a property and then just accessing same.) But this of course needs to be done in user code and the RTL can't force it. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 06.03.2013 11:45, schrieb Florian Klaempfl: Conclusion: With FPC, the optimization of threadvar access is not necessary. Instead it is highly recommended to always use thread specific instances of the classes that do the threaded work. TThread of course provides this out of the box. And how does one the "current" TThread? Since a few weeks: TThread.CurrentThread ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Wed, Mar 06, 2013 at 10:50:10AM +0100, Daniël Mantione wrote: > > > Op Tue, 5 Mar 2013, schreef Henry Vermaak: > > >Damn. My custom config kernel compiles stable kernels in 3-5 minutes on > >a quad core Xeon, which isn't bad. Did you build with the standard > >config? > > What is the standard config? As the operating system is Scientific > Linux 6, I'm using the config for the standard 2.6.32 kernel with as > little modifications as possible to use it for 3.3.2. Sorry, meant something like standard distro config, i.e. not localmodconfig or customised. > I don't have a 4 core Xeon system, but I tried to simulate it on a > dual Xeon 2670 system by only using 4 cores: > > [root@node037 src]# time numactl --physcpubind=0-3 make -j 4 > > ... > > real11m45.748s > user38m30.405s > sys 4m48.634s 3.8.2 with standard debian config on 4 core xeon: real28m19.009s user84m16.092s sys 7m18.327s ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/06/2013 11:45 AM, Florian Klaempfl wrote: So (as with all x86 variants) no library or system call is necessary. Wrong. This is not true in the general case, please read the appropriate api documents. I do know that on Windows it's documented like this by Microsoft. But I also know that the Microsoft C compiler (and AFAIK, gnu as well) does not adhere to that documentation but simply uses the appropriate selector register that the Intel chip designers happily provided for such kind of purpose. (We already discussed this here some years ago.) Wrong. On linux this can be done by a jump to a certain adress. OK. I did not thoroughly enough check into this. Does the jump to the system region automatically provide the mode switch without changing anything in the MMU (and this without the necessity to invalid the cache) ? If yes a glibc library call might provide a noticeable overhead and it might be advantageous to do the system call directly in the RTL. And how does one the "current" TThread? Do you mean something like this: Type TMyThread = class(TThread) private currentthread: Integer; end. var threads: array[1..100] of TMyThread; for i := 1 to 100 do begin thread[i] := TMyThread.Create; thread[i].currentthread := i; end; TMyThread.Execute; var s: String; begin s := 'I am ' + InToString(currentthread); end; ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 06.03.2013 11:12, schrieb Michael Schnell: So (as with all x86 variants) no library or system call is necessary. Wrong. This is not true in the general case, please read the appropriate api documents. With Cortex, this has changed to the use of the CP15 Register (freeing A9 to allow for better optimization). Now, CP15 is in fact not very suitable for this purpose, as it can only be accessed with privileged instructions and thus not in user mode (where the TLS in fact is invented for).Thus a system call (or trap) is needed to get the address of a threadvar. Wrong. On linux this can be done by a jump to a certain adress. Conclusion: With FPC, the optimization of threadvar access is not necessary. Instead it is highly recommended to always use thread specific instances of the classes that do the threaded work. TThread of course provides this out of the box. And how does one the "current" TThread? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/04/2013 12:47 PM, Michael Schnell wrote: In all fpc enabled patforms I examined (X86 Windows, X86 Linux, X64-64 Windows, X86-64 Linux, ARM Linux (32 Bits) the platform provides as well library calls as dedicated threadvar pointer registers. In windows the registers seem to be undocumented but obviously "stable", as a change would break a lot existing C/C++ software. All C/C++ compilers I examined used the threadvar pointer Registers for speed.. FWIW: I rechecked this and can add these results: With ARM, the pre-Cortex Arch on Linux uses A9 as a pointer to the TLS (Thread local Storage http://en.wikipedia.org/wiki/Thread-local_storage , that holds the threadvars). So (as with all x86 variants) no library or system call is necessary. With Cortex, this has changed to the use of the CP15 Register (freeing A9 to allow for better optimization). Now, CP15 is in fact not very suitable for this purpose, as it can only be accessed with privileged instructions and thus not in user mode (where the TLS in fact is invented for). Thus a system call (or trap) is needed to get the address of a threadvar. As a system call supposedly is rather costly on ARM (invalidating the cache, as here, (other than with x86) the cache is closer to the CPU than the MMU) using a library call will not do additional harm. Generally: The frequent access to threadvars is necessary with threaded programs that use the same code in multiple threads to allow for each thread to find easily out "who I am" even in a deeply nested function environment. But in an object driven language, this can easily be overcome by creating an instance of an object for each thread and with that, you always have the "Self" pointer as a thread specific entity. Happily "Self" resides on the stack that is dedicated for each thread, anyway, and is created automatically for any "procedure or object". So the use of any threadvar is necessary only when creating the thread-related object but it's not necessary to access any threadvar frequently. Conclusion: With FPC, the optimization of threadvar access is not necessary. Instead it is highly recommended to always use thread specific instances of the classes that do the threaded work. TThread of course provides this out of the box. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Tue, 5 Mar 2013, schreef Henry Vermaak: Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config? What is the standard config? As the operating system is Scientific Linux 6, I'm using the config for the standard 2.6.32 kernel with as little modifications as possible to use it for 3.3.2. I don't have a 4 core Xeon system, but I tried to simulate it on a dual Xeon 2670 system by only using 4 cores: [root@node037 src]# time numactl --physcpubind=0-3 make -j 4 ... real11m45.748s user38m30.405s sys 4m48.634s Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Henry Vermaak wrote: On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote: Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. Well... I put that into question. I don't have a 256 core system, but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a bit of compute power. Compiling kernel 3.3.2: [root@node016 linux-3.3.2]# time make -j 64 ... real1m54.823s user77m14.178s sys 11m32.109s Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config? Noting that for this test to be valid you obviously have to start from e.g. make clean and might usefully consider a reboot to make sure that all caches are empty. My point however was that a kernel build parallelises to very good effect, even where each processor is "implausibly slow" by today's standards. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote: > > > Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: > > >I've not had an opportunity to try this, but my understanding is > >that on a Sun E10K with something like 256 400MHz processors the > >Linux kernel built in around 20 seconds. I've had it build in > >about 3 minutes on a system with 16x 80MHz processors, but that > >was in the days of kernel 2.2 and there was probably less than > >half today's number of files involved. > > Well... I put that into question. I don't have a 256 core system, > but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a > bit of compute power. Compiling kernel 3.3.2: > > [root@node016 linux-3.3.2]# time make -j 64 > > ... > > real1m54.823s > user77m14.178s > sys 11m32.109s Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 05.03.2013 20:58, Graeme Geldenhuys wrote: On 2013-03-05 17:09, waldo kitty wrote: on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages... Thanks for you input. It sounds similar to what I was planning. Simply create an empty file in /tmp when each independent package is compiled successfully. Another process keeps checking /tmp for all the 0 byte files in expects. If they all exist, then build the test suite. Once that is complete, remove all the 0 byte files, and run the test suite. Now the question is, how good is fpmake? Will it can do something like that, or must I build my own system using scripts or console apps etc. I didn't yet experiment that much with fpmake, but considering that fpmake.pas files are just plain Pascal programs... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-05 17:09, waldo kitty wrote: > > on another system i work with, we use disk-based breadcrumb semaphore files > for > the different stages and parts of those stages... Thanks for you input. It sounds similar to what I was planning. Simply create an empty file in /tmp when each independent package is compiled successfully. Another process keeps checking /tmp for all the 0 byte files in expects. If they all exist, then build the test suite. Once that is complete, remove all the 0 byte files, and run the test suite. Now the question is, how good is fpmake? Will it can do something like that, or must I build my own system using scripts or console apps etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. Well... I put that into question. I don't have a 256 core system, but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a bit of compute power. Compiling kernel 3.3.2: [root@node016 linux-3.3.2]# time make -j 64 ... real1m54.823s user77m14.178s sys 11m32.109s To minutes to build a kernel is still fast though :) Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Ivanko B wrote: so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies. == Disk I/O is a huge low-down to avoid on any price (like databases do with their indexing). Today me tested building LINUX kernel 3.8.0 on 8*SMT=16 CPU system (Corei7 2G) + 32G DDR3 + 175(wr)/350(rd)MB/s RAID1. And this monster outperformed another cheap E8400 + 4G machine by only 2 times and most probably because the cheap machine was non-RAIDed. And because Core i* arch can't have proper DMA. I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. make -j has a dramatic effect on an SMP system, particularly if it can find groups of jobs without too much interdependence. If there's a lot of shared input files etc., then my experience is that it tends to level out at around -j 8 since it's extremely difficult to improve the cache architecture beyond that point. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
"make -j 16 deb-pkg" vs "make -j 2 deb-pkg", sure :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies. == Disk I/O is a huge low-down to avoid on any price (like databases do with their indexing). Today me tested building LINUX kernel 3.8.0 on 8*SMT=16 CPU system (Corei7 2G) + 32G DDR3 + 175(wr)/350(rd)MB/s RAID1. And this monster outperformed another cheap E8400 + 4G machine by only 2 times and most probably because the cheap machine was non-RAIDed. And because Core i* arch can't have proper DMA. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 3/5/2013 05:50, Graeme Geldenhuys wrote: I'm also trying to use fpmake for other "hourly build server" tasks, where I need to do clean compiles of various independent packages first, then build the test suite that pulls everything together. eg: building Synapse, FBLib, tiOPF, EpikTimer, fpGUI etc in parallel. Then somehow wait until they are all done, then build the test suite which uses all those packages. I still haven't figure this process out yet. If you have hints or suggestion on this, it would be greatly appreciated [maybe follow-up in a new message thread in fpc-pascal] on another system i work with, we use disk-based breadcrumb semaphore files for the different stages and parts of those stages... one is created when the section is entered into and another when the section is successfully compiled... it is mostly all C stuff and uses make... it is all pretty much FM to me as i only start it and wait for it to reach my modules and see if they compile or fail... if they fail, i (w)hack at them some more... the breadcrumbs allow the compilation environment to pick up where it left off instead of spending two hours recompiling everything again up to the point of failure... maybe this can give you some ideas? FWIW: the above breadcrumb system that i speak of is in the development version of an open source firewall product that i work with ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > That does't work, since in FPC an unit is an interface AND an > > implementation. And inline functions are in the implementation, not the > > interface. > > > > The only way is to simply toss the modular system (units) out, and work with > > $i, declare functions as externals in headers, let the compiler spit out > > dependencies. > > OK, I'll drop this line of enquiry then :) Thanks for the information > (and the patience). No problem at all, writing it down helped me see things more clearly too. I before never thought about the incremental build aspect. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Henry Vermaak schrieb: I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then? Yes and no. It would mean to create kind of header files for the Pascal units, usable to compile the units independently. No problem at a first glance, the Interface is the equivalent of an C header file, and the Uses lists are equivalent to further #includes. One of the remaining problems are the lost unit qualifiers, so that external references in the object files cannot be safely resolved. But in fact above is what FPC already does! When it encounters a Uses list, it loads the according PPU or, if not available or outdated, compiles the requested unit. Thus the PPU files already *are* the equivalent of the C header files. Plus the bonus that every "header" has to be loaded only once, not for every single module to be compiled by an C compiler. The problem IMO is the long list of units waiting for their dependencies loaded, before the first unit can be compiled at all (top-down). More efficient were bottom-up compilation, starting with the units with only few dependencies, so that compilation could start while the disk is stressed by loading all other PPU files, required for the compilation of units with more dependencies. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 11:44:37AM +0100, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > >>But on the other hand, if an application programmer could > > > >>disable FPC's unit handling and use make -j instead, choosing > > > >>to pay the price of difficult maintenance, it might defuse the > > > >>criticism coming from certain quarters. > > > >> > > > >Make can not figure out the dependencies between units by itself > > > >as it would need to parse them. > > > > > > That's for the user to do, if he thinks he can do a better job than FPC. > > > > Or implement an option that spits out the dependencies for make, so that > > the user doesn't have to do this. > > That does't work, since in FPC an unit is an interface AND an > implementation. And inline functions are in the implementation, not the > interface. > > The only way is to simply toss the modular system (units) out, and work with > $i, declare functions as externals in headers, let the compiler spit out > dependencies. OK, I'll drop this line of enquiry then :) Thanks for the information (and the patience). Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-05 10:31, Henry Vermaak wrote: > > Ah, I remember that fpmake can build with multiple threads, so perhaps > this is a better solution than to do it with make. I'll investigate. I've got that option enabled by default for building FPC 2.7.1 and it does shave off a few seconds. I'm also trying to use fpmake for other "hourly build server" tasks, where I need to do clean compiles of various independent packages first, then build the test suite that pulls everything together. eg: building Synapse, FBLib, tiOPF, EpikTimer, fpGUI etc in parallel. Then somehow wait until they are all done, then build the test suite which uses all those packages. I still haven't figure this process out yet. If you have hints or suggestion on this, it would be greatly appreciated [maybe follow-up in a new message thread in fpc-pascal] Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > >>But on the other hand, if an application programmer could > > >>disable FPC's unit handling and use make -j instead, choosing > > >>to pay the price of difficult maintenance, it might defuse the > > >>criticism coming from certain quarters. > > >> > > >Make can not figure out the dependencies between units by itself > > >as it would need to parse them. > > > > That's for the user to do, if he thinks he can do a better job than FPC. > > Or implement an option that spits out the dependencies for make, so that > the user doesn't have to do this. That does't work, since in FPC an unit is an interface AND an implementation. And inline functions are in the implementation, not the interface. The only way is to simply toss the modular system (units) out, and work with $i, declare functions as externals in headers, let the compiler spit out dependencies. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > IMHO a threading clusterfsck is preferable to a forking clusterfck :-) > > My gut feeling would be that the complexity and potential bugs/races > don't make up for the speed, but maybe a threaded compiler gains a lot > more than I imagine. Are there any multi-threaded compilers around for > comparison? Not the normal free ones. But that is not really a metric, but none of them were designed for modular languages, stronger, they don't even use features like precompiled headers that commercial ones already have for a long time. Note that strictly only the part of make *must* be multithreaded, the compilation of a compilation unit is basically the current single threaded compiler running in its own thread. So the parts that decide which compilation unit must be loaded, and parts of the unit loader. I think the problem is more doing it in a non-trivial production compiler, than the principle itself. > > This means you need to manually specify in the build system which > > compilation unit depends on which headers. And this is also why in C/C++ > > inline functions are in the header, so that this model is persistent, since > > most builds are not full, but incremental. > > As you probably know, you can use -MD and variants with gcc, which > outputs dependency files for make, that you then include in the > Makefile. No, but I did know other tools for that yes. Compiler output is better of course. > If you add, e.g. -MMD to the CFLAGS, these dependencies are > generated as a side effect of the compilation process, so it's not a > separate step. As a result, partial builds work really well, and can be > parallelized as usual. No manual work involved. Maybe that works for FPC too. But FPC can currently compile units multiple times afaik. (to detangle circular references), FPC afaik also registers some preprocessor state, and compiles on change. So basically make is meant for a different execution model IMHO, and it shouldn't be made a cornerstone. It is only a stopgap till we have something that fits with the unit system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, 5 Mar 2013, Mattias Gaertner wrote: Michael Van Canneyt hat am 5. März 2013 um 11:09 geschrieben: On Tue, 5 Mar 2013, Sven Barth wrote: Am 05.03.2013 10:58, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. As this is something we (as in the FPC developers) don't need: patches are welcome. [or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ] There is a new tool "pas2fpm.pp" which can easily be adapted to do this. It already calculates the dependencies, but outputs them in fpmake form. Is this correct: You need the tool pas2fpm to feed the tool fpmake to feed the tool fpc to feed linker, lazres You don't need anything. You can create fpmake.pp yourself. pas2fpm makes it easier for you. Just like "configure" and "autoconf" make it easier to create Makefiles if you use C. But because pas2fpm parses your units to do its job, it can go wrong, even on legal code. So using it should be optional. You could try and integrate all in 1 tool (like in an IDE as lazarus). fpmake was set up so it can be integrated completely in lazarus if you want it. Same for fppkg. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 11:09:39AM +0100, Michael Van Canneyt wrote: > > There is a new tool "pas2fpm.pp" which can easily be adapted to do this. > It already calculates the dependencies, but outputs them in fpmake form. Ah, I remember that fpmake can build with multiple threads, so perhaps this is a better solution than to do it with make. I'll investigate. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Michael Van Canneyt hat am 5. März 2013 um 11:09 geschrieben: > > > On Tue, 5 Mar 2013, Sven Barth wrote: > > > Am 05.03.2013 10:58, schrieb Henry Vermaak: > >> On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: > >>> Sven Barth wrote: > Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: > > But on the other hand, if an application programmer could > > disable FPC's unit handling and use make -j instead, choosing > > to pay the price of difficult maintenance, it might defuse the > > criticism coming from certain quarters. > > > Make can not figure out the dependencies between units by itself > as it would need to parse them. > >>> That's for the user to do, if he thinks he can do a better job than FPC. > >> Or implement an option that spits out the dependencies for make, so that > >> the user doesn't have to do this. > > As this is something we (as in the FPC developers) don't need: patches are > > welcome. > > > > [or you could try whether the ppdep tool still works: > > http://www.freepascal.org/tools/ppdep.var ] > > There is a new tool "pas2fpm.pp" which can easily be adapted to do this. > It already calculates the dependencies, but outputs them in fpmake form. Is this correct: You need the tool pas2fpm to feed the tool fpmake to feed the tool fpc to feed linker, lazres Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 11:05:22AM +0100, Sven Barth wrote: > Am 05.03.2013 10:58, schrieb Henry Vermaak: > >On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: > >>Sven Barth wrote: > >>>Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: > But on the other hand, if an application programmer could > disable FPC's unit handling and use make -j instead, choosing > to pay the price of difficult maintenance, it might defuse the > criticism coming from certain quarters. > > >>>Make can not figure out the dependencies between units by itself > >>>as it would need to parse them. > >>That's for the user to do, if he thinks he can do a better job than FPC. > >Or implement an option that spits out the dependencies for make, so that > >the user doesn't have to do this. > As this is something we (as in the FPC developers) don't need: > patches are welcome. I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then? I'm not ordering anyone to implement features, I'm exploring solutions to the depressing fact that my c projects compile quicker than my fpc projects (simply because my build system can launch parallel jobs). I don't think that turning fpc into a multi-threaded compiler is a sane thing to do. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, 5 Mar 2013, Sven Barth wrote: Am 05.03.2013 10:58, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. As this is something we (as in the FPC developers) don't need: patches are welcome. [or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ] There is a new tool "pas2fpm.pp" which can easily be adapted to do this. It already calculates the dependencies, but outputs them in fpmake form. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Henry Vermaak wrote: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. Possibly augmented by timestamp-based validity checking. Yes, but I didn't want to muddy the water by suggesting too many things at once :-) Seriously: if FPC's putting too much internal work into sorting out dependencies and somebody is prepared to write his code for an alternative build system, then give him enough rope. But it would obviously shine a harsh light on the compiler if this turned out not to be the major bottleneck. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 05.03.2013 10:58, schrieb Henry Vermaak: On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. As this is something we (as in the FPC developers) don't need: patches are welcome. [or you could try whether the ppdep tool still works: http://www.freepascal.org/tools/ppdep.var ] Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote: > Sven Barth wrote: > >Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: > >> > >>But on the other hand, if an application programmer could > >>disable FPC's unit handling and use make -j instead, choosing > >>to pay the price of difficult maintenance, it might defuse the > >>criticism coming from certain quarters. > >> > >Make can not figure out the dependencies between units by itself > >as it would need to parse them. > > That's for the user to do, if he thinks he can do a better job than FPC. Or implement an option that spits out the dependencies for make, so that the user doesn't have to do this. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 05.03.2013 10:41, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. In theory you can do it already. Compile each unit with "-Ur" (release unit) and the compiler will not attempt to recompile such a unit and prefer to fail. And then you do a compilation run for each unit. Good luck though for circular dependencies (the legal ones). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Sven Barth wrote: Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. That's for the user to do, if he thinks he can do a better job than FPC. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd: Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. Make can not figure out the dependencies between units by itself as it would need to parse them. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Marco van de Voort wrote: But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). But on the other hand, if an application programmer could disable FPC's unit handling and use make -j instead, choosing to pay the price of difficult maintenance, it might defuse the criticism coming from certain quarters. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. --- Inflicting this on the Pascal masses is unrealistic and undesirable. == 100% ! C(++) building system is a nightmare. It hardly worths to take. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mon, Mar 04, 2013 at 09:25:02PM +0100, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > > I just add all the objects to a variable in a Makefile. > > > > > > > > The result is that I have a 27000 line c library that compiles in *half* > > > > the time it takes to compile a 4000 line lazarus program because my c > > > > lib can be built with make -j 9. > > > > > > I'm not exactly sure what this proves. The C situation is not equivalent > > > to > > > the Pascal situation, the latter trying to make sure all (Pascal level > > > symbols) are there before the linker. > > > > What I'm trying to say is that gcc is going 3 times faster on my quad > > core machine because of the build system, not because they've turned > > their compiler into a multi-threaded clusterfsck. > > IMHO a threading clusterfsck is preferable to a forking clusterfck :-) My gut feeling would be that the complexity and potential bugs/races don't make up for the speed, but maybe a threaded compiler gains a lot more than I imagine. Are there any multi-threaded compilers around for comparison? > Yes. But is that incremental? It is fun to speed up a full build, but in > reality developers are more likely to do a partial one. Ever pressed F9 > after a small change in Delphi? The app starts nearly immediately, if > the change wasn't too deep in the hierarchy of dependencies. > > But compilation units in C have weaker(no) coherence than in (modular) > Pascal, and C does > not have an auto build system. All dependencies are done manually. > (sometimes assisted with semi automated tools) > > This means you need to manually specify in the build system which > compilation unit depends on which headers. And this is also why in C/C++ > inline functions are in the header, so that this model is persistent, since > most builds are not full, but incremental. As you probably know, you can use -MD and variants with gcc, which outputs dependency files for make, that you then include in the Makefile. If you add, e.g. -MMD to the CFLAGS, these dependencies are generated as a side effect of the compilation process, so it's not a separate step. As a result, partial builds work really well, and can be parallelized as usual. No manual work involved. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > > I just add all the objects to a variable in a Makefile. > > > > > > The result is that I have a 27000 line c library that compiles in *half* > > > the time it takes to compile a 4000 line lazarus program because my c > > > lib can be built with make -j 9. > > > > I'm not exactly sure what this proves. The C situation is not equivalent to > > the Pascal situation, the latter trying to make sure all (Pascal level > > symbols) are there before the linker. > > What I'm trying to say is that gcc is going 3 times faster on my quad > core machine because of the build system, not because they've turned > their compiler into a multi-threaded clusterfsck. IMHO a threading clusterfsck is preferable to a forking clusterfck :-) Yes. But is that incremental? It is fun to speed up a full build, but in reality developers are more likely to do a partial one. Ever pressed F9 after a small change in Delphi? The app starts nearly immediately, if the change wasn't too deep in the hierarchy of dependencies. But compilation units in C have weaker(no) coherence than in (modular) Pascal, and C does not have an auto build system. All dependencies are done manually. (sometimes assisted with semi automated tools) This means you need to manually specify in the build system which compilation unit depends on which headers. And this is also why in C/C++ inline functions are in the header, so that this model is persistent, since most builds are not full, but incremental. To build (possibly incremental) an interweaved codebase means handling complete control to make, and essentially means castrating FPC to the gcc model of one process, one compilation unit (and killing all auto dependency tracking and no recompile unless updated). This also means that for every codebase dependencies must be maintained. There might be semi-automated tools for it, but it is always a manual responsibility in the end. This is more or less done for the RTL. If it fails however, the result is partial builds, and errors pascal people are not used to. Of course you can also try to identify isolated groups of uses that can be build in parallel, and try to build those, with autobuild within that group. This happens in the packages/ directory, where only the dependency graph of whole dirs is maintained. > assuming that the same can't be achieved with pascal, then (without > making the compiler itself multi-threaded)? Basically, there is a small piece of make in the compiler for incremental building, and determining what sources need to be compiled (just handing a mainmodule +dirs to the compiler will build it all). This means the compiler can make decisions outside make's control, and also does extra checks (to find a consistent state for the code that abides the modular system before linking) As shown above, you can work around that with makefile generators (packages/) or hard work (rtl/). But for dynamic codebases of closely knit units like IDEs and compilers there really is no solution atm. If you have an option to force the compiler to only compile one unit, you could emulate the C model. You could even improve on the C situation by letting the compiler terminate on inconsistent incremental build state (to signal the dependencies are fscked) But even when in theory (which I btw don't even want to consider), you are equivalent to C in this way, it basically means disabling the unit system, and users must start to manual maintain dependencies, and learn to interpretate cryptic errormessages if an incremental build goes haywire. C users and developers are trained in this, and have their experience in detangling the web of deps etc, have developed semi-automated helper tools etc. Inflicting this on the Pascal masses is unrealistic and undesirable. Sticking to the manual build principles because the FPC devels can handle it essentially means that nobody else will have parallel builds, or will resort to a system of doing full builds only. (but that is throwing away the big savings to gain small ones). Something that big C projects resort to anyway, I'm told. And FPC even only in a few critical points. Manual maintenance is simply too painful (and atypical for modular languages and its users). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mon, Mar 04, 2013 at 11:19:38AM +0100, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > Manually maintaining dependencies between compilation units is stone-age. > > > > I just add all the objects to a variable in a Makefile. > > > > The result is that I have a 27000 line c library that compiles in *half* > > the time it takes to compile a 4000 line lazarus program because my c > > lib can be built with make -j 9. > > I'm not exactly sure what this proves. The C situation is not equivalent to > the Pascal situation, the latter trying to make sure all (Pascal level > symbols) are there before the linker. What I'm trying to say is that gcc is going 3 times faster on my quad core machine because of the build system, not because they've turned their compiler into a multi-threaded clusterfsck. In my ignorance, I'm assuming that the same can't be achieved with pascal, then (without making the compiler itself multi-threaded)? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/04/2013 12:29 PM, Tomas Hajny wrote: It's questionable whether it should be responsibility of a compiler to provide efficient support for threadvars, If the target platform does not support threadvars a compiler can't do it at all. If the target platform only provides library calls, a compiler needs to use them. If the target platform provides dedicated pointer registers for threadvars a compiler can use them. In all fpc enabled patforms I examined (X86 Windows, X86 Linux, X64-64 Windows, X86-64 Linux, ARM Linux (32 Bits) the platform provides as well library calls as dedicated threadvar pointer registers. In windows the registers seem to be undocumented but obviously "stable", as a change would break a lot existing C/C++ software. All C/C++ compilers I examined used the threadvar pointer Registers for speed.. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mon, March 4, 2013 10:33, Michael Schnell wrote: > On 03/04/2013 10:07 AM, Michael Van Canneyt wrote: >> >> We use pthreads on non-windows, and GetTLS/SetTLS on Windows. >> > Thus the situation is as it was when we discussed this some years ago: a > library call with each access to a threadvar, making fpc a lot slower > that the C compiler (Microsoft and GNU, no idea about other brands) on > that behalf (that might nob be very relevant in real life) . . . It's questionable whether it should be responsibility of a compiler to provide efficient support for threadvars, or whether the target platform should provide more efficient support for them in its design and its libraries (here MS Windows API, Posix threads, etc.). The OS/2 target does not need any API call for accessing threadvars (thanks to the OS/2 design using "virtualization" features provided by the Intel architecture) and there is no compiler magic involved. Admittedly, this may not scale well to all types of CPU architectures (i.e. function call to a platform API may be more appropriate in the end to allow simpler and more powerful CPU architectures alike), but there is no need why the platform API should be more complicated (i.e. slower) than the simple pointer access (as used with the OS/2 implementation for threadvar access) on a CPU architecture providing such features. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > Manually maintaining dependencies between compilation units is stone-age. > > I just add all the objects to a variable in a Makefile. > > The result is that I have a 27000 line c library that compiles in *half* > the time it takes to compile a 4000 line lazarus program because my c > lib can be built with make -j 9. I'm not exactly sure what this proves. The C situation is not equivalent to the Pascal situation, the latter trying to make sure all (Pascal level symbols) are there before the linker. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, Mar 02, 2013 at 05:26:02PM +0100, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > I don't see why there would be more synchronization overhead than make? > > > > So why not keep it simple and let the build system handle parallel jobs? > > I like autobuilding. IMHO that is a core attraction of unit based (modular) > languages. > > Manually maintaining dependencies between compilation units is stone-age. I just add all the objects to a variable in a Makefile. The result is that I have a 27000 line c library that compiles in *half* the time it takes to compile a 4000 line lazarus program because my c lib can be built with make -j 9. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/04/2013 10:07 AM, Michael Van Canneyt wrote: We use pthreads on non-windows, and GetTLS/SetTLS on Windows. Thus the situation is as it was when we discussed this some years ago: a library call with each access to a threadvar, making fpc a lot slower that the C compiler (Microsoft and GNU, no idea about other brands) on that behalf (that might nob be very relevant in real life) . (BTW: a similar discussion arises with any thread-synchronization primitive AFAIK here dynamic library calls are done while an arch-depending Futex/Mutex implementation directly in the RTL _could_ be done. But here, a C user (Linux) would do the same library call to pthreadlib "mutex...()" which does "Futex"if available in that arch, and "Mutex" if not. ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mon, 4 Mar 2013, Michael Schnell wrote: On 03/04/2013 09:49 AM, Michael Van Canneyt wrote: The solution must work on ALL platforms... Of course. I don't remember ever having seen a system (Windows, Linux, x86, ARM, NIOS (similar top MIPS) ) where the C compiler does a library call when accessing a threadvar. Usually a register is dedicated for this purpose that is loaded with a thread specific value by the OS. I do know C compiler implementations that don't support threadvars at all and thus are unable to support FUTEX and with that low level thread synchronization is a lot slower as always a userland/system switch is necessary. Here hardware (atomic instructions) and the OS implementation (e.g. "Atomic Region" to overcome such limitations for userland) comes into play. I remember from a discussion some years ago that fpc uses a (supposedly arch/platform depending) library call with any access to to a threadvar instead of using the appropriate (arch/platform depending) register. But I did not recheck recently. We use pthreads on non-windows, and GetTLS/SetTLS on Windows. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/04/2013 09:49 AM, Michael Van Canneyt wrote: The solution must work on ALL platforms... Of course. I don't remember ever having seen a system (Windows, Linux, x86, ARM, NIOS (similar top MIPS) ) where the C compiler does a library call when accessing a threadvar. Usually a register is dedicated for this purpose that is loaded with a thread specific value by the OS. I do know C compiler implementations that don't support threadvars at all and thus are unable to support FUTEX and with that low level thread synchronization is a lot slower as always a userland/system switch is necessary. Here hardware (atomic instructions) and the OS implementation (e.g. "Atomic Region" to overcome such limitations for userland) comes into play. I remember from a discussion some years ago that fpc uses a (supposedly arch/platform depending) library call with any access to to a threadvar instead of using the appropriate (arch/platform depending) register. But I did not recheck recently. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mon, 4 Mar 2013, Michael Schnell wrote: On 03/02/2013 04:02 PM, Florian Klaempfl wrote: In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. I suppose the (high level) synchronization will be rather complex and eat performance. The low level threadvar implementation is known to be improvable. AFAIR, it uses library calls as well in Windows as in Linux while the appropriate C compilers use segment registers (on x86 / x86-64) which are documented in Linux and undocumented in Windows and supposedly a lot faster. The "(on x86 / x86-64)" disqualifies your argument for use. The solution must work on ALL platforms... BTW. threadvars in FPC are done in the same way as in Delphi, with TLS. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03/02/2013 04:02 PM, Florian Klaempfl wrote: In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. I suppose the (high level) synchronization will be rather complex and eat performance. The low level threadvar implementation is known to be improvable. AFAIR, it uses library calls as well in Windows as in Linux while the appropriate C compilers use segment registers (on x86 / x86-64) which are documented in Linux and undocumented in Windows and supposedly a lot faster. OTOH, are Theradvars necessary to be used very frequently (i.e. more than when creating thread-specific objects, that then can be used to access the thread specific data) ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Michael Van Canneyt said: > I'm sorry, but I do not share your focus on speed. I have many projects, > some of them have more units than mseide does, and yet I never have to wait > more than a couple of seconds. The only exception is the Lazarus IDE. No, I have also seen it with Indy and the JCL. In the JCL case I tried to isolate it even, (and managed to 3 or 4 units). And over the years, that are not the only cases. > If you say that mseide only compiles with -B, I would suggest looking for > strange dependencies inside mseide, if you want to reduce compile time... No, afaik there is certainly a problem in the compiler. Afaik I heard devs that unit dependencies cycles with more than two units are not always detected clearly (and probably that implies some hidden interface-implementation dependencies?) > I do not want to say that FPC does not need speed improvements, but I do > suspect you > will get faster results looking at removing the -B requirement from mseide... That's for sure. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:11, schrieb Martin Schreiber: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. I checked again, time of FPC linking stage is about 2.5 seconds. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sun, 3 Mar 2013, Martin Schreiber wrote: On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote: On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. When you do, please send me the output of a strace -f I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible. BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. A sure sign that you have fishy code :) I have lots of code, and never ever experienced such a thing. I even can't remember when the compiler last gave me a problem; and I use it daily. Most problems I experience today have to do with version management. I'm sorry, but I do not share your focus on speed. I have many projects, some of them have more units than mseide does, and yet I never have to wait more than a couple of seconds. The only exception is the Lazarus IDE. If you say that mseide only compiles with -B, I would suggest looking for strange dependencies inside mseide, if you want to reduce compile time... I do not want to say that FPC does not need speed improvements, but I do suspect you will get faster results looking at removing the -B requirement from mseide... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03.03.2013 11:08, Martin Schreiber wrote: On Sunday 03 March 2013 10:42:09 Sven Barth wrote: Do you mean compiling the compiler? If so than for real tests you SHOULD NOT compile the compiler by hand, but only through "make cycle" in the compiler directory or "make all" in the top level directory. This will ensure that the compiler is compiled correctly. And yes, I know the problem with -B and it's likely related to unit loading. This normally happens only in more complex projects like the compiler. Though I've just managed yesterday to create a smaller example (by accident) that also chrashes. Maybe I'll find the problem and can fix it once and for all :) No, I mean MSEide. MSEide is a more complex application than the compiler it seems. :-) No, it's not (at least not in that sense ;) ), because the compiler triggers this error as well, when I compile it inside the IDE. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 10:42:09 Sven Barth wrote: > > Do you mean compiling the compiler? If so than for real tests you SHOULD > NOT compile the compiler by hand, but only through "make cycle" in the > compiler directory or "make all" in the top level directory. This will > ensure that the compiler is compiled correctly. > > And yes, I know the problem with -B and it's likely related to unit > loading. This normally happens only in more complex projects like the > compiler. Though I've just managed yesterday to create a smaller example > (by accident) that also chrashes. Maybe I'll find the problem and can > fix it once and for all :) > No, I mean MSEide. MSEide is a more complex application than the compiler it seems. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 03.03.2013 08:23, Martin Schreiber wrote: On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote: On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. When you do, please send me the output of a strace -f I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible. BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. Do you mean compiling the compiler? If so than for real tests you SHOULD NOT compile the compiler by hand, but only through "make cycle" in the compiler directory or "make all" in the top level directory. This will ensure that the compiler is compiled correctly. And yes, I know the problem with -B and it's likely related to unit loading. This normally happens only in more complex projects like the compiler. Though I've just managed yesterday to create a smaller example (by accident) that also chrashes. Maybe I'll find the problem and can fix it once and for all :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 03.03.2013 10:46, schrieb Martin Schreiber: > On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote: >> Op Sun, 3 Mar 2013, schreef Martin Schreiber: >>> BTW, a significant percentage of the time is waiting for FPC compiling >>> because FPC normally crashes without -B. >> >> I think you should focus your efforts on getting those bugs fixed, such as >> by submitting bug reports that allow reproduction of the problem with >> programs as simple as you can get them to show the problem. >> > The problem is well known since a long time AFAIK. The answer we normally get > when we report a unit handling related FPC crash is that FPC unit handling > should be rewritten. I can't rewrite FPC unit handling myself because I have > many other tasks. ;-) Same here :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote: > Op Sun, 3 Mar 2013, schreef Martin Schreiber: > > BTW, a significant percentage of the time is waiting for FPC compiling > > because FPC normally crashes without -B. > > I think you should focus your efforts on getting those bugs fixed, such as > by submitting bug reports that allow reproduction of the problem with > programs as simple as you can get them to show the problem. > The problem is well known since a long time AFAIK. The answer we normally get when we report a unit handling related FPC crash is that FPC unit handling should be rewritten. I can't rewrite FPC unit handling myself because I have many other tasks. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Sun, 3 Mar 2013, schreef Martin Schreiber: BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. I think you should focus your efforts on getting those bugs fixed, such as by submitting bug reports that allow reproduction of the problem with programs as simple as you can get them to show the problem. It is completely unrealistic that FPC will get the same compiler speed as Delphi. FPC will become slower in the future for sure, because the compiler will execute more algorithms to generate better code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote: > On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: > > On Sat, 2 Mar 2013, Martin Schreiber wrote: > > > On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: > > >> Anyway, what seems obvious from your numbers is that it is the linking > > >> stage that needs speedup. This does not really come as a surprise. > > > > > > On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll > > > check it later, currently I try to make MSEide+MSEgui Kylix3 compatible > > > so we have a benchmark on Linux too. > > > > When you do, please send me the output of a strace -f > > I will take a while because it is much work to make the code both FPC and > Delphi/Kylix compatible. > BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: > On Sat, 2 Mar 2013, Martin Schreiber wrote: > > On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: > >> Anyway, what seems obvious from your numbers is that it is the linking > >> stage that needs speedup. This does not really come as a surprise. > > > > On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll > > check it later, currently I try to make MSEide+MSEgui Kylix3 compatible > > so we have a benchmark on Linux too. > > When you do, please send me the output of a strace -f > I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible. > It will allow me to see what IO the Delphi/Kylix compiler does. > > We can say for sure that the fact you use .pas as filename extension > will cause FPC to do twice the number of stat() calls, because .pp is > searched first...Logical therefore that the IO is slower. > AFAIK "*.pas" is Delphi compatible? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Graeme Geldenhuys wrote: On 2013-03-02 10:28, Michael Van Canneyt wrote: We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower. Second time I hear this this week. Can we (in our own copies of FPC) change this to search .pas first? If so, where in the source? Search for sourceext and pasext. fppu.pas: Found:=UnitExists(sourceext,hs); fppu.pas: Message1(unit_t_unitsearch,ChangeFileExt(sourcefn,sourceext)); fppu.pas: fnd:=FindFile(ChangeFileExt(sourcefn,sourceext),'',true,hs); globals.pas: sourceext = '.pp'; options.pas: if FileExists(inputfilepath+ChangeFileExt(inputfilename,sourceext)) then options.pas:inputfilename:=ChangeFileExt(inputfilename,sourceext) scanner.pas: found:=findincludefile(path,ChangeFileExt(name,sourceext),foundfile); Be careful when changing this, because the compiler will then also search for rtl/fcl/package source files with different names, which may result in nasty surprises. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-02 10:28, Michael Van Canneyt wrote: > We can say for sure that the fact you use .pas as filename extension > will cause FPC to do twice the number of stat() calls, because .pp is > searched first...Logical therefore that the IO is slower. Second time I hear this this week. Can we (in our own copies of FPC) change this to search .pas first? If so, where in the source? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 16:49, schrieb Michael Van Canneyt: All this said: You will not hear me claiming that there is no room for improvement in FPC. I'm sure there is. However, I do not think we'll be able to match Delphi's speed without sacrificing the main goal of FPC: to support as much platforms as possible. Well, not to mention the goal of maintainability. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 17:24, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: I don't see why there would be more synchronization overhead than make? In a parallelized compiler symtables etc. might be shared and this might require a lot of synchronization to prevent data corruption. With make, the different units can be seperated much better by a human than the compiler can do. Only if you want to avoid multiply used units to be only once in memory. IMHO if you are afraid of that, then don't do that :-) Forking compilers on a by unit level instead of some meta level is typically slower because reading ppus takes a lot of time. Not to mention the huge effort it would be to get the compiler parallelized internally. As said the first step can be relatively simple. Get rid of globals some more, and then only the parts before compile() needs to be changed. In theory, yes. In practice this is a huge effort. Just one example: inlining requires that the node tree of a procedure is copied. However, during copying the tree is annotated for proper copying. Bottom line: even if the compiler finished to compile a unit, the generated info is not read only. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > I don't see why there would be more synchronization overhead than make? > > So why not keep it simple and let the build system handle parallel jobs? I like autobuilding. IMHO that is a core attraction of unit based (modular) languages. Manually maintaining dependencies between compilation units is stone-age. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Florian Klaempfl said: > > I don't see why there would be more synchronization overhead than make? > > In a parallelized compiler symtables etc. might be shared and this might > require a lot of synchronization to prevent data corruption. > With make, the different units can be seperated much better by a human > than the compiler can do. Only if you want to avoid multiply used units to be only once in memory. IMHO if you are afraid of that, then don't do that :-) > Not to mention the huge effort it would be to get the compiler > parallelized internally. As said the first step can be relatively simple. Get rid of globals some more, and then only the parts before compile() needs to be changed. The rest more or less runs as is, and the linker remains single threaded after all compile threads have finished? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Craig Peterson wrote: On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt wrote: If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. You cannot ignore the implementation details. Making abstraction of these details means ignoring the benefits that follow from these details: It is exactly these details that allow FPC to support so many platforms, and why Delphi is stuck with Windows and remote compiling/debugging for MaCOS. Delphi does not even run on these platforms ! FPC does. If you are - like Martin, I suspect - not interested in weird and exotic platforms then of course FPC's implementation choice and the attached consequences present you with a disadvantage because of these 'implementation details'. But if you are interested in ARM, raspberry PI, MIPS and whatever there is out there, it is these implementation details that make FPC the only possible choice. All this said: You will not hear me claiming that there is no room for improvement in FPC. I'm sure there is. However, I do not think we'll be able to match Delphi's speed without sacrificing the main goal of FPC: to support as much platforms as possible. So, proposals for improvement are most welcome. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, Mar 02, 2013 at 04:23:32PM +0100, Marco van de Voort wrote: > In our previous episode, Florian Klaempfl said: > > >> Better parallize the building using some build units. Then it will be > > >> probably compiled in less than 10 sec on a modern CPU. > > > > > > Better paralellize the compiler :-) > > > > In theory yes but I still fear that the threadvars and synchronization > > eats much of the advantage in this case. > > I don't see why there would be more synchronization overhead than make? So why not keep it simple and let the build system handle parallel jobs? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 16:23, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. I don't see why there would be more synchronization overhead than make? In a parallelized compiler symtables etc. might be shared and this might require a lot of synchronization to prevent data corruption. With make, the different units can be seperated much better by a human than the compiler can do. Not to mention the huge effort it would be to get the compiler parallelized internally. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Florian Klaempfl said: > >> Better parallize the building using some build units. Then it will be > >> probably compiled in less than 10 sec on a modern CPU. > > > > Better paralellize the compiler :-) > > In theory yes but I still fear that the threadvars and synchronization > eats much of the advantage in this case. I don't see why there would be more synchronization overhead than make? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 15:15, schrieb Craig Peterson: On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt wrote: If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. A more apt comparison would be that we hired the painters to paint the outside of the house and one of them did the inside too because his tools require him to paint both sides of the walls. While the other one can paint only in one color and only buildings with one floor ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 13:24, schrieb Marco van de Voort: In our previous episode, Florian Kl?mpfl said: (for example renaming all files to .pp takes off +/- 1 second here) Nevertheless, I'd be interested in seeing the strace. Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt wrote: > If you hire 2 painters to paint the whole of your house, > and one doesn't paint the inside, "because you don't see it from the > outside", of course he will be finished faster; he didn't perform the same > work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. A more apt comparison would be that we hired the painters to paint the outside of the house and one of them did the inside too because his tools require him to paint both sides of the walls. -- Craig Peterson Scooter Software ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: Compiled with which FPC version? trunk. ??? MSEgui compiles with trunk? It is mostly unicodestring centric, so that shouldn't be such a surprise? MSEgui has an own unicodestring manager on Linux which must be adapted to cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses some hacks with UnicodeStrings which must be adapted. I don't want to do the work before Unicode handling in FPC is finished and documented. And frankly, I don't believe in it anymore... Clearly, you have not been watching SVN, because Paul Ishenin is currently integrating the native Object Pascal unicode string manager in trunk. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote: > In our previous episode, Martin Schreiber said: > > > > Compiled with which FPC version? > > > > > > trunk. > > > > ??? MSEgui compiles with trunk? > > It is mostly unicodestring centric, so that shouldn't be such a surprise? MSEgui has an own unicodestring manager on Linux which must be adapted to cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses some hacks with UnicodeStrings which must be adapted. I don't want to do the work before Unicode handling in FPC is finished and documented. And frankly, I don't believe in it anymore... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Martin Schreiber said: > > > > > > Compiled with which FPC version? > > > > trunk. > > ??? MSEgui compiles with trunk? It is mostly unicodestring centric, so that shouldn't be such a surprise? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
> Am 01.03.2013 18:33, schrieb Martin Schreiber: >> Hi, >> >> In order to have a good benchmark for FPC Afaik Delphi 7 is closed source, so inherently worse than any version of FPC. Cheers, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Florian Kl?mpfl said: > > (for example renaming all files to .pp takes off +/- 1 second here) > > > > Nevertheless, I'd be interested in seeing the strace. > > Better parallize the building using some build units. Then it will be > probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:28, schrieb Michael Van Canneyt: > > > On Sat, 2 Mar 2013, Martin Schreiber wrote: > >> On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: >>> >>> Anyway, what seems obvious from your numbers is that it is the linking >>> stage that needs speedup. This does not really come as a surprise. >>> >> On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll >> check it >> later, currently I try to make MSEide+MSEgui Kylix3 compatible so we >> have a >> benchmark on Linux too. > > When you do, please send me the output of a strace -f > > It will allow me to see what IO the Delphi/Kylix compiler does. > > We can say for sure that the fact you use .pas as filename extension > will cause FPC to do twice the number of stat() calls, because .pp is > searched first...Logical therefore that the IO is slower. > > (for example renaming all files to .pp takes off +/- 1 second here) > > Nevertheless, I'd be interested in seeing the strace. Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:21, schrieb Martin Schreiber: > On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: >> I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe >>> >>> Compiled with which FPC version? >> >> trunk. > > ??? MSEgui compiles with trunk? Compiled with WPO and -O4 it starts and I can edit text and forms. Nothing more tested. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. When you do, please send me the output of a strace -f It will allow me to see what IO the Delphi/Kylix compiler does. We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower. (for example renaming all files to .pp takes off +/- 1 second here) Nevertheless, I'd be interested in seeing the strace. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:15 schrieb "Martin Schreiber" : > > On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: > > > > >> I did a quick test on win32, it seems to be a little bit smaller than > > >> 2.6.2: > > >> > > >> 02.03.2013 10:09 5.774.848 mseide.exe > > > > > > Compiled with which FPC version? > > > > trunk. > > ??? MSEgui compiles with trunk? Surprise! :P We don't try to respect backwards compatibility for nothing. ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: > > >> I did a quick test on win32, it seems to be a little bit smaller than > >> 2.6.2: > >> > >> 02.03.2013 10:09 5.774.848 mseide.exe > > > > Compiled with which FPC version? > > trunk. ??? MSEgui compiles with trunk? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:16, schrieb Martin Schreiber: > On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote: >> Am 01.03.2013 22:40, schrieb Martin Schreiber: >>> On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: Am 01.03.2013 18:33, schrieb Martin Schreiber: > Hi, > > In order to have a good benchmark for FPC Expect the next release to be even slower. >>> >>> Will it produce better code instead? >> >> What means better? Faster? Less buggy? Smaller? >> > It means faster and smaller, Delphi 7 produced code is smaller and faster > than > FPC 2.6.2 code. For i386-win32 maybe. A compiler must be bug free anyway. ;-) > >> I did a quick test on win32, it seems to be a little bit smaller than >> 2.6.2: >> >> 02.03.2013 10:09 5.774.848 mseide.exe > > Compiled with which FPC version? trunk. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote: > Am 01.03.2013 22:40, schrieb Martin Schreiber: > > On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: > >> Am 01.03.2013 18:33, schrieb Martin Schreiber: > >>> Hi, > >>> > >>> In order to have a good benchmark for FPC > >> > >> Expect the next release to be even slower. > > > > Will it produce better code instead? > > What means better? Faster? Less buggy? Smaller? > It means faster and smaller, Delphi 7 produced code is smaller and faster than FPC 2.6.2 code. A compiler must be bug free anyway. ;-) > I did a quick test on win32, it seems to be a little bit smaller than > 2.6.2: > > 02.03.2013 10:09 5.774.848 mseide.exe Compiled with which FPC version? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: > > Anyway, what seems obvious from your numbers is that it is the linking > stage that needs speedup. This does not really come as a surprise. > On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Fri, 1 Mar 2013, Martin Schreiber wrote: Am 01.03.2013 20:52, schrieb Michael Van Canneyt: For a correct test, you should not enable debug information in FPC. Or enable generation of turbo debug information and the corresponding linker map in Delphi. Otherwise you are comparing apples with pears, as -D+ in delphi does not do nearly the same thing as -g in FPC. From an end user point of view comparison of compiletime with debug info is correct IMHO because one needs debug info for development. Absolutely. I am not arguing with that. But Delphi does not generate any real debug info with $D+. You need the actual units (dcu) to be able to debug. You cannot debug anything with an external debugger unless you enable turbo debugging info. With FPC you can use (well must) an external debugger. So FPC creates info readable by an external debugger. If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work. Therefor to compare what is actually comparable, and by this I mean that both compilers perform the same tasks, you must enable generation of turbo debugging and the linker map info in delphi. This means additional work for the Delphi compiler and therefor will slow down Delphi too. (in fact quite a lot, if I recall my work with AQTime). Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 01.03.2013 22:40, schrieb Martin Schreiber: > On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: >> Am 01.03.2013 18:33, schrieb Martin Schreiber: >>> Hi, >>> >>> In order to have a good benchmark for FPC >> >> Expect the next release to be even slower. >> > Will it produce better code instead? > What means better? Faster? Less buggy? Smaller? I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: > Am 01.03.2013 18:33, schrieb Martin Schreiber: > > Hi, > > > > In order to have a good benchmark for FPC > > Expect the next release to be even slower. > Will it produce better code instead? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 01.03.2013 18:33, schrieb Martin Schreiber: > Hi, > > In order to have a good benchmark for FPC Expect the next release to be even slower. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 01.03.2013 20:52, schrieb Michael Van Canneyt: For a correct test, you should not enable debug information in FPC. Or enable generation of turbo debug information and the corresponding linker map in Delphi. Otherwise you are comparing apples with pears, as -D+ in delphi does not do nearly the same thing as -g in FPC. From an end user point of view comparison of compiletime with debug info is correct IMHO because one needs debug info for development. with ppc386.exe -O2 -CX -XX -Xs -B -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\audio -Fu..\..\lib\common\opengl -Fu..\..\lib\common\report -Fu..\..\lib\common\db -Fu..\..\lib\common\crypto -Fu..\..\lib\common\graphics -Fu..\..\lib\common\i18n -Fu..\..\lib\common\kernel\windows -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 -Fu..\..\lib\common\delphicompatibility -Fu..\..\lib\common\fpccompatibility -omseidefp.exe mseide.pas: 489756 lines compiled, 56.8 sec , 3309520 bytes code, 2691084 bytes data F:\proj\mseide-msegui\apps\ide>dir mseidefp.exe Datenträger in Laufwerk F: ist win2000_F Datenträgernummer: 5C58-C4EF Verzeichnis von F:\proj\mseide-msegui\apps\ide 01.03.2013 20:186'025'728 mseidefp.exe That said, it takes about 30 seconds on Linux on a laptop to do the same thing. Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz (A centrino - whatever all these numbers mean today) On the same machine with OpenSUSE 12.2 and ppc386 -O2 -CX -XX -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp.exe mseide.pas: I had to kill the process after 10 minutes, 1GB is not enough to smartlink 32 bit MSEide. For 64bit MSEide 2GB are not enough for smartlinking. ppc386 -O2 -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp mseide.pas: 495808 lines compiled, 64.8 sec -rwxr-xr-x 1 mse users 7453980 Mar 1 22:10 mseidefp ppc386 -O2 -g -Xg -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel -Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report -Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics -Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux -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 -Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility -omseidefp mseide.pas: 495808 lines compiled, 102.9 sec -rwxr-xr-x 1 mse users 7459160 Mar 1 22:14 mseidefp Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Michael Van Canneyt said: > > In our previous episode, Michael Van Canneyt said: > >> What I remember from windows 2000 is that FPC/ld/etc is several factors > >> slower on the same hardware as when run under Linux. > > > > Afaik the internal linker is default on windows since 2.2.0 ? > > Also when smartlinking ? I think that was one of the primary reasons for it even. Before the internal linker, smartlinking lazarus (every unit in it) with LD could eat 1.5GB On *nix, sections smartlinking remedied that somewhat, but on Windows not. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Fri, 1 Mar 2013, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: What I remember from windows 2000 is that FPC/ld/etc is several factors slower on the same hardware as when run under Linux. Afaik the internal linker is default on windows since 2.2.0 ? Also when smartlinking ? I am not sure about this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Michael Van Canneyt said: > What I remember from windows 2000 is that FPC/ld/etc is several factors > slower on the same hardware as when run under Linux. Afaik the internal linker is default on windows since 2.2.0 ? There are still some issues with external .a archives, which is why the makefiles afaik enable the external linker for the textmode IDE (libgdb) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Fri, 1 Mar 2013, Michael Van Canneyt wrote: On Fri, 1 Mar 2013, Martin Schreiber wrote: Hi, In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7 compatible again. Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649): http://gitorious.org/mseide-msegui For a correct test, you should not enable debug information in FPC. Or enable generation of turbo debug information and the corresponding linker map in Delphi. Otherwise you are comparing apples with pears, as -D+ in delphi does not do nearly the same thing as -g in FPC. That said, it takes about 30 seconds on Linux on a laptop to do the same thing. Forgot to say that this is done using the 64-bit, unoptimized version of FPC, which is probably slow when compared to the 32-bit optimized version of FPC. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel