Re: [gnugo-devel] multi-board branch

[Arend Bayer]

> I read http://trac.gnugo.org/gnugo/ticket/24 and the corresponding mail
> thread. It seems a very important step for GNU Go, (for sizing on SMP/cluster
> with more or less deep look-ahead, i guess you know this ;) and if i
> understand well, it could be very usefull for other things.

Yes, it's very unfortunate the discussion stalled at the time (and I feel
partially guilty for that); however, if we think the patch is the right
solution I will volunteer to revive it.

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.

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

This needs more discussion.

Arend