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