Re: [gnugo-devel] multi-board branch

[Dave Denholm]

Arend Bayer <address@hidden> writes:

> Since dual core processor are becoming more and more commont, it would
> indeed be nice if we could support this in GNU Go.
>
> There is an alternative to the approach of this patch: instead of running
> GNU Go with two threads, one could fork off a second instance of GNU Go,
> and delegate e.g. some of the life-and-death reading to the other GNU Go.
> Communication to this 2nd GNU Go would be via GTP; I would imagine a new
> GTP command to dump the content of persistent caches from one instance
> to another.
>

Any particular reason to use gtp ?  A binary protocol is likely to be faster.

> The latter approach has the advantage that it is simpler, and doesn't punish
> single-processor machines. The disadvantage is that it probably will never
> be as effective. For example, the two instances will not be able to share
> the non-persistent cache, which would be possible with two threads (although
> I am sure we would get the locking wrong for a couple of bug rounds).
>

It is possible to share memory across processes, but you just need to
set it up slightly differently. Eg mmap() a block of memory from
/dev/zero

It might be considered an advantage to not share, though : the child
process would inherit a copy of the parent's cache, but subsequent
writes would not update the master copy, and so don't need locks.



One thing to bear in mind is that if you are memory-bound, you might
not be able to exploit hyperthreading fully.


dd
-- 
Dave Denholm              <address@hidden>       http://www.esmertec.com