Author: Robert Hyatt
Date: 06:44:18 04/17/01
Go up one level in this thread
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... :) The pointer issue is _not_ a big one. At most it costs a couple of percent 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...
This page took 0.02 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.