Re: [fpc-pascal] CPU affinity of TThread descendants
On Mon, 19 Jan 2009, David W Noon wrote: > Hi, > > I am running FPC 2.3.1 under Linux 2.6.26 on a twin CPU AMD Athlon MP > system. > > Whenever I instantiate multiple descendants of the TThread class, they > all seem to run on the same CPU, which is the same CPU as the parent > thread is running on. With 21 threads in the program, the system monitor > shows one CPU at 100% busy and the other CPU idle. > > Does this class, by default, impose CPU affinity, in the manner of the > Windows NT/2K/XP CreateThread() API? If so, how can I disable this? > [I.e., I want all my threads to be runnable by any CPU inside the box.] No CPU affinity is imposed as far as I know; Under Linux, this is not possible, at least I've never heard of such a call. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Assembler as not found, switching to external assembling
On 19 Jan 2009, at 18:05, Ingemar Ragnemalm wrote: One of the users reporting problems did search for as, and found it in /developer/usr/bin/as! So Xcode was installed, and "as" was installed, but not in /usr/bin/as! Maybe Apple has changed the paths in some Xcode version? I have no problems on my MBP/10.5 though. Perhaps an alias from /usr/bin/as would help? Or is there anything else that FPC needs? As of Xcode 3.x, you can install multiple versions of Xcode at the same time on a system. To allow for this, Xcode can install everything it needs into a a subdirectory, without installing anything globally on the system (i.e., nothing under /usr, /var, ..., only things under whatever directory you decide to install Xcode in). However, for compatibility with standard unix development environments and configure/makefile-based source distributions, you still have the option to also install the command line utilities (such as automake, autoconf, as, ld, gcc, cpp, ...) globally under /usr. Now, I am pretty certain that this is done by default and that this is only not done if you choose a custom install and deselect that option. I don't have an Xcode installer lying around to verify that though. If it is not the default anymore, I'm not sure how FPC itself could solve it, because as mentioned earlier, you can install Xcode anywhere. I could add a default configuration option so that FPC also searches under /Developer/usr/bin for the assembler/linker, but that would not necessarily be enough. On the other hand, the whole reason of existence of that Xcode installation option is exactly for programs such as FPC. Jonas PS: the option to tell FPC where to search for as and ld is -FD ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CPU affinity of TThread descendants
Original-Nachricht > Datum: Tue, 20 Jan 2009 09:07:54 +0100 (CET) > Von: Michael Van Canneyt > An: FPC-Pascal users discussions > Betreff: Re: [fpc-pascal] CPU affinity of TThread descendants > > > On Mon, 19 Jan 2009, David W Noon wrote: > > > Hi, > > > > I am running FPC 2.3.1 under Linux 2.6.26 on a twin CPU AMD Athlon MP > > system. > > > > Whenever I instantiate multiple descendants of the TThread class, they > > all seem to run on the same CPU, which is the same CPU as the parent > > thread is running on. With 21 threads in the program, the system monitor > > shows one CPU at 100% busy and the other CPU idle. > > > > Does this class, by default, impose CPU affinity, in the manner of the > > Windows NT/2K/XP CreateThread() API? If so, how can I disable this? > > [I.e., I want all my threads to be runnable by any CPU inside the box.] > > No CPU affinity is imposed as far as I know; > Under Linux, this is not possible, at least I've never heard of such a > call. sched_set_affinity() sched_get_affinity() (Now you've heard. ;) The default for the CPU masks should be all 1s though, so the scheduler should distribute the threads evenly to all available CPUs. But... AFAIR the affinity mask is inherited by child processes, so maybe the main thread already has some affinity mask set (well, I don't see no reason why it should, but you never know). So for the original poster I'd suggest inserting a sched_get_affinity() call and check the resulting bit mask. If that's not all 1s, one should investigate the reason... if it is, then maybe the scheduler detects too many dependencies between the threads, so it doesn't distribute the thread on both CPUs, or maybe there's one totally different reason for the behaviour... Vinzent. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CPU affinity of TThread descendants
In our previous episode, "Vinzent H?fler" said: > > > [I.e., I want all my threads to be runnable by any CPU inside the box.] > > > > No CPU affinity is imposed as far as I know; > > Under Linux, this is not possible, at least I've never heard of such a > > call. > > sched_set_affinity() > sched_get_affinity() > > (Now you've heard. ;) > > The default for the CPU masks should be all 1s though, so the scheduler > should distribute the threads evenly to all available CPUs. But... AFAIR > the affinity mask is inherited by child processes, so maybe the main > thread already has some affinity mask set (well, I don't see no reason why > it should, but you never know). > So for the original poster I'd suggest inserting a sched_get_affinity() > call and check the resulting bit mask. If that's not all 1s, one should > investigate the reason... if it is, then maybe the scheduler detects too > many dependencies between the threads, so it doesn't distribute the thread > on both CPUs, or maybe there's one totally different reason for the > behaviour... Maybe the dynloader tries to detect somehow if the binary is modern, by searching for some gcc generated symbol that is not there in the FPC bins, and reverts to something old. (e.g. to keep older threading code running). Note that there is also a trend towards more asymetric multiprocessing, as already a dual cpu system of multicore processors is not symmetric anymore (moving threads between CPUs too often decreases cache utilization). It might be a byproduct/bug of such modifications in that particular kernel, specially if he is on a distro that likes to add own patches to kernels. (since it seems the OP is using a dual singlecore cpu system) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] DCPCrypt as part of FCL?
DCPCrypt information http://wiki.lazarus.freepascal.org/DCPcrypt. Couldn't DCPCrypt become part of FCL packages? I noticed there is already a Blowfish unit in FCL-Base directory. I think there are some hash implementations as well. DCPCrypt is quite complete in the encryption and hash department. :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DCPCrypt as part of FCL?
In our previous episode, Graeme Geldenhuys said: > DCPCrypt information > http://wiki.lazarus.freepascal.org/DCPcrypt. > > Couldn't DCPCrypt become part of FCL packages? I noticed there is > already a Blowfish unit in FCL-Base directory. I think there are some > hash implementations as well. DCPCrypt is quite complete in the > encryption and hash department. :-) 1. Did you contact the author? Licensewise it is already ok I think (MIT/BSD license without advocacy clause), but it is the decent thing to do nonetheless. 2. Did you validate its working on 64-bit and big endian machines? That is a requirement before we can even think about adding. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DCPCrypt as part of FCL?
On Tue, Jan 20, 2009 at 3:55 PM, Marco van de Voort wrote: > > 1. Did you contact the author? Licensewise it is already ok I think (MIT/BSD > license without advocacy clause), but it is the decent thing to do > nonetheless. I have not, but I don't mind doing so. > 2. Did you validate its working on 64-bit and big endian machines? That is a > requirement before we can even think about adding. I can test on a 64bit system, but not a big endian machine. Can anybody help with the latter? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DCPCrypt as part of FCL?
On Tue, January 20, 2009 14:39, Graeme Geldenhuys wrote: > DCPCrypt information > http://wiki.lazarus.freepascal.org/DCPcrypt. > > > Couldn't DCPCrypt become part of FCL packages? I noticed there is > already a Blowfish unit in FCL-Base directory. I think there are some > hash implementations as well. DCPCrypt is quite complete in the > encryption and hash department. :-) Two general questions from my side: 1) I assume you meant adding it as another package within the FPC tree, not to fcl-base in particular or so, right? 2) As with all other packages: Do we know who'd be maintaining this package? In other words, is the potential maintainer known (volunteering for that task), or are you trying to find one (as the first step before adding this as a new package)? Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DCPCrypt as part of FCL?
On Tue, Jan 20, 2009 at 4:50 PM, Tomas Hajny wrote: > > 1) I assume you meant adding it as another package within the FPC tree, > not to fcl-base in particular or so, right? I meant somewhere in the FPC tree. Where exactly is up to the FPC developers. But I would guess the FCL would be the general location. > 2) As with all other packages: Do we know who'd be maintaining this > package? In other words, is the potential maintainer known (volunteering I got no idea who is the actual maintainer of the code in Lazarus CCR on SourceForge repository. David Barton is the original author of DCPCrypt for Delphi and Kylix. Somebody named Barko ported it in 2006 to Free Pascal & Lazarus. I don't think anybody worked on it since, but the original DCPCrypt also hasn't increased in version since 2006. Anyway, I don't mind maintaining it as we (our company) currently use it with FPC 2.2.3 in our projects. So we would always require a working version. Encryption is a big part of our flagship product and will notice anything broken very quickly. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DCPCrypt as part of FCL?
In our previous episode, Graeme Geldenhuys said: [ Charset UTF-8 unsupported, converting... ] > On Tue, Jan 20, 2009 at 3:55 PM, Marco van de Voort wrote: > > > > 1. Did you contact the author? Licensewise it is already ok I think (MIT/BSD > > license without advocacy clause), but it is the decent thing to do > > nonetheless. > > I have not, but I don't mind doing so. Good. This mostly is important to create willingness to accept FPC related upstream patches. > > 2. Did you validate its working on 64-bit and big endian machines? That is a > > requirement before we can even think about adding. > > I can test on a 64bit system, but not a big endian machine. Can > anybody help with the latter? Not me currently. Half of my computer room is packed up pending a new roof, including the mini. Note another thing to check is if there are unit names in that archive that already exist. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DCPCrypt as part of FCL?
On Tue, Jan 20, 2009 at 5:10 PM, Marco van de Voort wrote: > > Good. This mostly is important to create willingness to accept FPC related > upstream patches. OK, I'll contact the author tomorrow when I am back at work. > Not me currently. Half of my computer room is packed up pending a new roof, > including the mini. I know the feeling! :-) I lost my study / computer room which had to become the new nursery. Our newborn get priority. So all my hardware (the wife calls it junk) is now stashed in the garage. You wouldn't believe how much one can collect over the years! My winter project is to build a loft room which will become my study. I can't wait! :-) > Note another thing to check is if there are unit names in that archive that > already exist. All the DCPCrypt units and include files start with the prefix dcp and I haven't noticed any conflicts with FPC units yet. So that's a good sign. The only inconsistency in DCPCrypt is the file case. Some are upper- and some are lower case. But that's easy to fix. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CPU affinity of TThread descendants
On Tue, 2009-01-20 at 11:34 +0100, Vinzent Höfler wrote: > Original-Nachricht > > Datum: Tue, 20 Jan 2009 09:07:54 +0100 (CET) > > Von: Michael Van Canneyt [snip] > > No CPU affinity is imposed as far as I know; > > Under Linux, this is not possible, at least I've never heard of such a > > call. > > sched_set_affinity() > sched_get_affinity() Correct spelling: sched_setaffinity() sched_getaffinity() > (Now you've heard. ;) There are also pthread_setaffinity_np() and pthread_getaffinity_np(), where the "_np" suffix is a mnemonic for "non-portable". > The default for the CPU masks should be all 1s though, so the scheduler > should distribute the threads evenly to all available CPUs. But... AFAIR > the affinity mask is inherited by child processes, so maybe the main > thread already has some affinity mask set (well, I don't see no reason > why it should, but you never know). > > So for the original poster I'd suggest inserting a sched_get_affinity() > call and check the resulting bit mask. If that's not all 1s, one should > investigate the reason... if it is, then maybe the scheduler detects too > many dependencies between the threads, so it doesn't distribute the > thread on both CPUs, or maybe there's one totally different reason for > the behaviour... I have checked the CPU masks for all threads and the first byte is always 0x03, which indicates that both CPUs can be considered for dispatching the thread. I have noticed one thing that might shed a little light on the topic: whenever I use a pipe for the output and I allow the pipe to stall with a full buffer, after execution is resumed the program sometimes restarts on the other CPU, but again all threads run on the same CPU. This would indicate to me that the child threads are tightly associated with the parent thread, as far as CPU selection goes. I will reimplement my code in C++ using wxWidgets and its wxThread class, and see what behaviour that produces. I might also reimplement the code in C, using the pthread_??? family of API calls in their raw state. This could be a bit ugly, as the code is decidedly object oriented. As it appears that this issue is at a lower level than the TThread class, we might need to examine the BeginThread() function of the RTL. However, it could be attributable to the threading library I use with Linux (NPTL, in my case). I shall report back with whatever I find. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Workaround for #0011837 (FPC <= 2.2.2 with GTK >= 2.13)
Vincent Snijders wrote: Yes, anybody can do that. Sorry? I don't get it. Giovanni ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
