Gian-Carlo Pascutto: <[EMAIL PROTECTED]>:
>Olivier Teytaud wrote:
>
>> Also, there are probably other people interested in combining
>> UCT and mpi; I don't know if some people have a more precise idea
>> of the level of the MPI+UCT combination than us. Someone ?
>
>MPI is just a parallel programming model/library, right?
>
>So the only thing to know is the effective[1] speedup of the MPI 
>version, and how well UCT scales with increasing timecontrols/speed.

No.  Remember UCT is a sequential algorithm.  Parallelizing UCT make 
playouts ineffective.  Increasing the number of threads and/or 
communicating delay decreases the effectiveness of the playouts.  With 
my experiments on a symmetrical threads implementation on a four core 
SMP system, winning rate against GNU Go decreases from 50.4+-1.1% 
to 46.7+-1.1%, which corresponds to -25 ELO, where 1.1% are the 
standard deviations [1].

[1] "A Study on Implementing Parallel MC/UCT Algorithm", GPW 2007 (in 
Japanese).
http://www.geocities.jp/hideki_katoh/publications/gpw2007/gpw07-private.pdf

-Hideki

>I believe Don has data on the latter and you should have data on the former.
>
>[1] How much faster you find the correct move. Not interesting is: how 
>many positions you search per second or how many playouts you do per second.
--
[EMAIL PROTECTED] (Kato)
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/

Reply via email to