[Computer-go] some general UCT notes.
ben.ellis at softweyr.co.uk
Tue Sep 2 06:18:46 PDT 2014
I agree the board-copying should possibly be quicker, but in your case I'd
think for the first half of the game you should starting from an empty
board and replay the moves to get to the current position and then doing
the opposite in the second half of the game by undoing the moves. You'd
have to approximate what "half way through the game" is of course :)
On Sat, Aug 30, 2014 at 9:10 PM, Dave Dyer <ddyer at real-me.net> wrote:
> I've recently been upgrading my family of UCT robots for non-go games,
> but thought I'd report a few things for "general knowledge and
> This UCT system is written in java, and runs on standard PC hardware with
> multiple processor cores.
> The system typically uses a fairly small tree and a relatively long random
> playout tail, and is not especially optimized for speed. Only the
> and backtrack-update phases have thread synchronization issues.
> I found simple threading had a pretty sharp knee in performance at 4
> threads. In other words, 2 3 and 4 threads improved the overall amount
> of work done more or less linearly to 3.5x, speed improvements fell off
> rapidly for more threads.
> I've also been comparing "blitz" play which creates a copy of the
> board at top level, and starts each descent with a copy of the board;
> compared with "unwinding" play where every move is explicitly unwound.
> Of course, the complexity of the unwinding varies a lot from game to
> game, but I found that "unwind" is always faster, an average 1/3 faster
> across several games. So if the complexity of unwinding your data
> structures is not too great, it's worthwhile.
> Computer-go mailing list
> Computer-go at dvandva.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go