I think Michael is saying that the MPI version is effectively a different program, although it's very similar.
So "effective speedup" could be slightly misleading. So on 2 processors we might imagine it might be 1.8 X faster by some measure, but it's probably not the same as a single processor thinking 1.8 X longer. Perhaps an effective way to measure the improvement is to find 30 positions that are fairly difficult but where there is only 1 clearly best move and then use it as a timing benchmark. But with the type of scoring that MC does (where we optimize for winning percentage over score) it's more difficult to construct go problems. You have to construct them so that you LOSE the game if you don't play the "right" move, but if you do play it you win the game. - Don Gian-Carlo Pascutto wrote: > Michael Williams wrote: >> Gian-Carlo Pascutto wrote: >>> 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. >>> >>> 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. >>> >> >> >> Not exactly, because the algorithm is probably not going to be >> exactly the same -- that would require too much communication between >> nodes. > > So what? That is not relevant, as long as the algorithm is still > "UCT-like" even when parallelized, so that Don's scaling research holds. > > How they parallelize is completely irrelevant as long as they measure > effective speedup, i.e. time to find the best move. There is > absolutely no requirement for the parallel algorithm to give the same > results. Only the (average) speed of the end result matters. > > If you know how much faster you are, and you know how much stronger > you get by being faster, you have the answer. Both data is available. > > Also good is: score versus a set opponent, or even better, set of > opponents. > _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
