Author: Vincent Diepeveen
Date: 08:56:02 04/17/01
Go up one level in this thread
On April 17, 2001 at 09:44:18, Robert Hyatt wrote: >On April 17, 2001 at 08:00:27, Vincent Diepeveen wrote: > >>On April 16, 2001 at 22:07:10, Robert Hyatt wrote: >> >>>On April 16, 2001 at 18:15:52, Dieter Buerssner wrote: >>> >>>>In a different discussion, Vincent wrote the following: >>>> >>>>>It is not difficult to implement the form of parallellism as used by >>>>>Rudolf. Invented by a frenchman who couldn't spell a word english and >>>>>who wrote an impossible article for JICCA (did anyone proofread it at >>>>>the time as i'm pretty sure they didn't get his parallel idea?). >>>>> >>>>>At the time when i read the article i was pathetically laughing about it >>>>>actually as i also didn't get the idea of the frenchman. But it appears >>>>>everyone who can make a chessprogram work under win2000 can also get >>>>>within an afternoon his program parallel to work. Then some debugging >>>>>and a day later it works cool. >>>> >>>>I'd be very interested in this algorithm, that can be implemented at an >>>>afternoon :-) >>>> >>>>Could you point elaborate on this. >>>> >>>>BTW. In Paderborn, Roland Pfister also told me, that he knows this from Rudolf >>>>Huber, and he even started to explain it to me. Somhow, we (or me) got >>>>distracted, and I cannot remember the essential things. >>>> >>>>What I remember is, that the time consuming work, of making your >>>>search/evaluation routines free from all those global variables is not needed. >>>> >>>>Regards, >>>>Dieter >>> >>> >>>Global variables will _always_ be a problem. Unless you avoid threads >>>altogether and use separate processes. But then you incur other penalties >>>you have to solve... >> >>Multiprocessing is faster anyway of course as multithreading as i >>do not need to read a stupid pointer. >> >>Arrays which are only read and not modified one can put in shared memory >>and read from there without penalties. >> >>The penalty for multithreading is, when using ansi-c conventions, >>way bigger as for multiprocessing. >> >>Multiprocessing is more than ok. >> >>Obviously it's not always so easy to get it to work, because of >>different causes >> - allocating shared memory in linux isn't simple >> - windows NT server/tuple server versions have the bad habit >> to always swap away shared memory to the cache when the allocated >> memory size is huge. >> - to share memory in NT in such a way that programs have the same >> virtual adress space is not evident, as there are 2 functions which >> one can use and one of them is not going to work for you. Don't need >> to mention that by accident i picked the wrong function initially :) >> >>Of course all the above problems are solvable > > >Just use your approach to search trees with 2 nodes. Then tell me how efficient >it is to use messages and pipes to get the other processes busy on such small >trees, compared to threads which have zero overhead... :) Sorry i'm missing the problem. I'm using shared memory for the parallellism within 1 node to get them so all i need to do is: g->gosearch = true; Then all processes start searching. Starting threads is more expensive! Obviously using more nodes to search at is more difficult but i have no idea how to start a thread over the network on a diff machine :) >The pointer issue is _not_ a big one. At most it costs a couple of percent For me it would be around 10% but go on. >in speed, but it also gives back a lot since threads can >look at other thread's >local memory if they know what they are doing... My entire search is in shared memory, i wouldn't know the difference between that memory and memory your thread look in.
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.