Hi and thanks for posting this interesting summary. The surprising thing is that 128 machines are much worse than 64; is this due to communication cost ? I would expect a stagnation more than a decrease of performance, but maybe the master/slave system does not have the logarithmic cost as a function of the number of nodes (whereas tree-like communications by averaging have a logarithmic number of communications per computaton node) and therefore you have a significant communication overhead with big number of computation nodes ?
For the bias point of view (your second paragraph below) I think we all have the same scalability limits, unfortunately... we've tried many things for including life&death analysis without any success. Best regards, Olivier In distributed mode doubling the number of machines initially gains > approximately 50 elo (half a stone) up to 8 machines. Above this we > quickly hit a scalability limit and the best result so far is with 64 > machines; this is the configuration used for the KGS tournament (starting > at round 4) and on KGS right now. 128 machines are currently much worse > than 64. > > Preliminary analysis of the lost games shows that the current code > has inherent scalability limits because the playouts are biased. > When the playouts incorrectly judge the life status of a group, > the results will be bad no matter how many cores and machines > work on it. We are of course working on this to eliminate these > scalability limits. > > >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
