Because we are multi-CPU rather than multi-core, we gave up on
keeping the persistent caches in sync.
My instinct is that Dave Denholm got this part right:
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.
I have often wondered how much of a penalty we pay for not sending
the cache data to each of the new threads, or the cache data from the
winner back up to the master.
We use MPI for message passing, and while I don't recommend against,
it is kind of a pain too. But one we still accept for now (we just
found one of our mpi bugs this morning). MPI works fine on a single
CPU, you just tell it how many threads you are willing to have at
each machine in a host file, so simulating a bigger cluster is not a
problem.
Cheers,
David
On 7, Mar 2006, at 11:46 PM, Terry McIntyre wrote:
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
[email protected]
http://lists.gnu.org/mailman/listinfo/gnugo-devel
_______________________________________________
gnugo-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnugo-devel
_______________________________________________
gnugo-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnugo-devel
