The million dollar question: How well does Mogo scale on this number of processors? Can you give us at least some kind of generalization?
My understanding is that on quad core machines you get most of the benefit by simply running parallel versions of the algorithm and sharing the data structure - but there must be many difficulties scaling this up to many machines over a network. Can I assume the data structure (tree) is distributed among different machines? - Don Olivier Teytaud wrote: > > For information on the mogo/pro challenge: > - during preliminary tests, mogo has won 4/0 against a very high level > human; at that time we were just very very very happy :-) > - some other humans, supposed to be weaker, have however > won some games at that time (before the nakade correction); > - the Nakade weakness is currently assumed to be solved, but I'm not sure > of that - at least mogo solves the "old" known nakade situations and is > stronger than the old mogo; at that time we were happy again :-) > - another improvement is that we currently have access to much > hardware than during tests above; > - but, a human, supposed to be weaker (non professional level, 5Dan > however) has found some trick to win against mogo; this is not the > nakade, but this is seemingly stable, and I am just not able of > explaining how he can do that; he has shown me situations and says that > "in this kind of situations, mogo makes an error", but I just don't > understand the common point in these situations. If we understand > something we will post details here (at least the sgf files)... > - in 9x9, the MPI (multi-machine) version of mogo wins with probability > 80% against the non-MPI version. The speed-up is better in 19x19 and > will be detailed later, after extensive experiments - the focus was > on 9x9 until now due to the challenge. > - once again, very strong improvements in front of old versions of mogo > leads to disappointing improvements against humans. However, I think > that the best 9x9 go programs (mogo and others) are currently difficult > opponents for high level players. > > Everything is under writing for publication and will be sent on this > mailing list. > Some technical details: > - due to concurrency in memory access, heavier playouts come for free. If > playouts are heavier (computationally more expensive) the speed-up > becomes better. The nakade-problem involves heavier playouts, but the > computational overhead is almost canceled by the speed-up improvement, > as the speed-limit on 8-core machine is due to concurrency in memory > access (for modifying the tree) more than to computational cost. > - (very) unfortunately, the opening books generated for mogo without > nakade are seemingly poor for mogo with nakade... this has destroyed > weeks of work. > > If mogo wins the challenge, I'd like to point out that this is a > collective success of the computer-go mailing list - without gnugo, > crazystone, cgos, kgs and so on, mogo would just not exist. Thanks to > all of you for that. I regret that due to some restrictions, > we have not published every detail before, but it was just a matter of > weeks and I'm happy that everything will be published soon, and if we > loose the challenge I hope someone else will win something similar > soon :-) > Olivier > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
