Author: Robert Hyatt
Date: 08:36:17 09/26/02
Go up one level in this thread
On September 26, 2002 at 07:58:37, Vincent Diepeveen wrote: >On September 25, 2002 at 16:13:45, Robert Hyatt wrote: > >>On September 25, 2002 at 14:51:30, Vincent Diepeveen wrote: >> >>>On September 25, 2002 at 11:49:25, Russell Reagan wrote: >>> >>>Windows doesn't work at all above 64 processors AFAIK. >>>Linux doesn't work above 8 processors AFAIK. >>> >>>But i'm looking for a cheap solution under linux now too >>>and i see nowhere at manual pages of linux an example of how >>>to do it. basically this is THE big problem under linux. >>> >>>MSDN under windows however shows about 100 examples how to >>>do WaitForSingleObject.\ >> >> >>Any idea how this is implemented? I do. It is a system call and it >>is just as ugly as select() or anything else... > >I'm not saying it is less ugly, i just cut'n pasted an example and it >worked, that's the important thing! > >> >> >>> >>>Of course other solutions to do the job are fine too here.>>I know under unix that the pthread libraries have something >>>called pthread_cond_wait. >>> >>>this is a great function, but i can't use it, as my program is >>>SMP, so SYMMETRIC MULTIPROCESSING. >> >>Don't follow that. pthreads is based on SMP. But I think you are >>just misusing a common term. SMP does not mean using fork() as you >>are doing. > >What i meant to say is that all my processes are the same, so any >of them can terminate the search. Not process 0. That's why i mentionned >the symmetric. Obviously it has nothing to do with fork or pthreadcreate. > >>But even with fork() processes, you can use the pthread stuff. Just stuff >>the things into shared memory... > >That i didn't know about linux of course, for irix it isn't the case however. >I already have tried it in fact already. Short before world champs, i had >to replace then that pthread lock function by spin_lock. I started with >the pthread functions you use in crafty. I don't use pthread_locks() in crafty. I use asm spin-locks. My locks are set for such a very small duration in time, pthread_mutexes are simply way too inefficient because they block the process if the lock is already held by another proces. That takes 100X longer to do than the lock-set duration... > >Anyway i will give it a shot in linux. I have to see it first that it works >before i believe it :) > >>> >>>It means that all processors are equal. It means that any >>>processor might terminate a certain iteration as last one. >>> >> >> >>really lost me there. I use pthreads and that is _exactly_ how >>my search works... > >What i meant to tell is that any of the processes may terminate the >search which means that they have to signal the i/o thread (which is >a thread of process 0) that there is a new iteration to start. > >I simply can't garantuee that process 0 is the last one to terminate. >In fact small chance even it happens :) > >>>This one has to signal the i/o thread, which is a thread from >>>some other process most likely (big chance with 512 processors). >>> >>>The current idea for linux is to sleep for 5 milliseconds and >>>checkout whether an iteration has finished. So that's a possible >>>waste of about 4 milliseconds times n moves (can be 50 or so), >>>so that's losing each ply 0.2 seconds. if you get in endgame 11 >>>ply out of hashtable that's 11 x 0.2 = 2.2 seconds. >>> >>>That is a big waste of seconds in a 1 0 game for example online >>>at a dual k7. >>> >> >>Don't do it like that... > >Exactly :) > >> >>> >>> >>> >>>>On September 25, 2002 at 08:10:06, Vincent Diepeveen wrote: >>>> >>>>>i cannot use select() at all as i limit myself to < 128 processor >>>>>partitions then. >>>> >>>>Does WaitForSingleObject or WaitForMultipleObjects allow you to use more than >>>>128 processors? >>>> >>>>>also i have no idea how to get it to work and whether it can do >>>>>it 400 times a second instantly. >>>> >>>>See the problems Microsoft causes? They always have to be different (in a bad >>>>evil kind of way).
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.