hideki_katoh at ybb.ne.jp
Wed Mar 10 01:16:03 PST 2010
In single thread UCT, a playout selects optimal move depends on the
result of previous playout. This gives best performance. With
multi-threaded UCT (assuming N threads), a playout cannot use
previous result but (N - 1) earlier playout, or has to ignore the
results of last (N - 1) playouts, which causes worse performance.
By my old experiments using GGMC Go on 9x9 board, one more thread
causes -10 Elo rating but this number should depend on the performance
and/or the implementation of the program, the board size, and so on.
David Fotland: <033001cac02b$d86c66b0$89453410$@com>:
>Has anyone tried the following experiment:
>Against a standard opponent (not the same program), compare scaling in time
>vs scaling in cores.
>For example run one core for X playouts against the opponent, then run four
>cores, each with X/4 playouts against the same opponent, and run one core
>with X/4 playouts.
>Now we can compare the difference between four times as much time on one
>core to four times as many cores. Most engines, including Many Faces, scale
>number of playouts linearly with number of cores, but for Many Faces, one
>core is quite a bit stronger than four cores when running the same number of
>When playing against Gnugo level 10 19x19, 8K playouts wins 87%. 32K
>playouts on one core wins 97%, but 32 playouts on four cores (8K each) only
>I'm curious if other programs scale strength better with more cores.
>Computer-go mailing list
>Computer-go at dvandva.org
gg at nue.ci.i.u-tokyo.ac.jp (Kato)
More information about the Computer-go