Computer Chess Club Archives




Subject: Re: Parallel algorithms in chess programming

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.
>>>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.01 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.