[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Simple multi-threading...

From: Jim Segrave
Subject: Re: [Bug-gnubg] Simple multi-threading...
Date: Sat, 6 Jan 2007 01:59:32 +0100
User-agent: mutt-ng/devel-r804 (FreeBSD)

On Fri 05 Jan 2007 (09:14 +0000), Jonathan Kinsey wrote:
> Happy new year to everyone!
> I know a while ago there was a branch in cvs looking at multiple
> evaluation threads, I'm not sure what happened to that and have written
> some (relatively) simple code to multi-thread AnalyzeGame().
> It seems to work ok, with a simple test taking 36secs rather than 61secs
>  with the old code (on a dual core laptop).
> There are a few small things to finish off, but the one thing I've
> currently not done is the Take/Drop to Double link in AnalyseMove().
> Basically the code remembers some evaluation info from a Double move
> record and uses this on a subsequent Take/Drop move record.  I commented
> this code out (as obviously the Take/Drop could be done at the same time
> as the Double) and couldn't see what wasn't happening.  Does anyone have
> more of an idea of what this code does, if it's important and can't be
> removed I'll have to pass in the Double move record to AnalyseMove and
> make sure that both move records are done together.
> Assuming it all works it should be relatively easy to use the same code
> in multiple evaluations/rollouts (although I've not looked or thought
> about this yet).  Are there any other areas that might be worth
> multi-threading?

You need to be careful with Double and Take/Drop. 
Evaluating a double provides _all_ the data needed for Take and

The problem caused by separating them was that if you rolled out a
doubling action, then used analyse match to update the statistics,
gnubg would go through the match, put the rollout statistics into the
results, come to the take/drop and discover that it needed an
evaluation (not a rollout). It did so, and this evaluation, associated
with the current board, overwrote the rollout results.

You really want everything done with Double/Take-Drop/Beaver to work
off the same evaluation. That's why there's a pointer to the eval
context in move record, rather than just the evaluation. For ordinary
moves, the pointer points into the same move record. For cube
decisions, the base evaluation is the one in the original double
record, the pointer in take/drop or beavers points back to that eval
in the double record, so that everything related to the double and the
response is working from the same base.

Jim Segrave           address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]