Gian-Carlo Pascutto: <[EMAIL PROTECTED]>: >Hideki Kato wrote: > >> 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]. > >This just shows that this SMP implementation has no *effective* speedup, >but probably a effective slowdown. And so a loss of ELO is expected.
Above are measured with fixed number of playouts. Speed is, of course, almost linearly up with the number of threads (within the number of cores). But I'm sorry I didn't read your [1] carefuly. It's my fault. >I clearly stated what I meant by effective: >"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." What is "correct" move? It has sense only for some artificial problems or very limited positions, and so, it cannot evaluate total performance of a program. >The fact that parallel UCT is not the same as serial UCT does not change >anything at all with the above definition. Either it finds good moves >faster, and hence is stronger, or it does not. I agree but how to? One way I can think of is to run a program on cgos or similarbut Olivier wrote it's not allowed. -Hideki -- [EMAIL PROTECTED] (Kato) _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
