Re: [gnugo-devel] multi-board branch

[Terry McIntyre]

With dual core systems less than $1000 nowadays, it would be real handy to have a multi-threading version of gnugo.  Even larger clusters are becoming affordable for the home enthusiast. A stack of five Mac Minis would be about $4000 -- about what one used to pay for a high-end personal computer not so long ago.

Easier said than done, however. David Doshay has put a considerable bit of effort into the Sluggo cluster; I have some experience way back with neural networks on multi-processor architectures. It's rather a fun challenge to get everything right. :)

Terry McIntyre

On Mar 7, 2006, at 11:21 PM, Arend Bayer wrote:

> > 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
>
>
>
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnugo-devel