Bojun Huang: <[email protected]>: >To steve uurtamo: > > >consensus 2 seems muddled. everyone would generally prefer to use as >>much CPU as they can lay their hands on, but a few things stop them > >Yes, there will be more programming challenges for massive parallelism, and >this is >definitely non-trivial work, but as long as there is enough benefit (say, the >continuously >increased ELO score, especially for those programs you call it the "top-end"), >someone will >achieve this anyway, even on system with hundreds or thousands of cores, >right? I think a >bigger problem may be that there are ELO score lost reported in those papers >about MCTS >parallelization, compared with single-core result with same playout number, >although I still >cannot get the intuition why there must be *considerable* lost for massive >parallelism, even >after careful and highly-dynamic task partitioning.
By my experiments on multithread shared tree parallelism, adding one thread loses about 10 Elo (compared to single thread with the same playout for a move). Maybe because, a newly starting thread cannot use the results of the threads between (ie, the results of already running N minus 1 threads; where N is the number of threads). So, even on SMP systems, the performance scales in logarithmic but the loss linearly scales in Elo. Getting correct number needs more experiments, though. >> the top end is whatever it is. what matters is advancing the >>ELO of real programs > >I think at least one of the goals of building GO bot is to beat human master, >and apparently >programs with 3000 ELO score in current CGOS cannot achieve this, right? If >you call them >(i.e. programs with 3000 score) as "top end", I think it would be more than >just "there is a >reason to worry about the top end, but that "we especially worry about it". > > > >to Hideki: > > >>NB: Classical programs such as Katsunari and GNU Go perform the same on >>laptops at the longer time-settings used for the Olympiads. > >The 9x9 champion in 2010 is MyGoFriend, it run at a notebook with i7 3GHz; >valkyria, rank 5 >in 9x9 GO 2010, its hardware setup is reported as "core2 duo"; there are some >others running >their program on single PC, which seems not very powerful. Although correct reasons could be given by the authors, I can guess some. Those authors simply didn't want carrying heavy desktop or server computers. 2010 Olympiad was held in Japan, far from Europe. Recent laptops are not so slower than typical core2 quad desktops, in addition. >>I believe there are no trade-off now. Quality is the most >>important issue for developing strong programs. If the simulations of a >>program can manage _almost all_ positions correctly, then I mind the >>trade-off. But this never happen in a few tens years, I guess. > >Yeah, seems most strong programs trade the playout speed off the playout >quality. No. Quality still priors speed for Zen. I don't think double the speed raises Zen19D (cluster version of Zen) to 6d on KGS. The quality of the simulations of current Zen (ver. 7.7) has the potential to have 5d on KGS. That's all. Still, there are so many positions Zen cannot manage correctly (I can see daily :-). >I guess >this is because the performance penalty is not that big for most >quality improvement. I have no idea about that. Obviously more precise, detailed analysis needs more time. Who knows where the trade-off point? More importantly, we don't know "what" is effective to have more powerful simulations. >According to David Fortland, the speed of MFG gets "only" 3x slower in recent years. >Apparently we cannot expect something "magic" by 3x speedup, but we could expect that for >those quality improvements (with the cost of 3x slowdown). Better algorithm is much more effective and important than speed, I'd like to say. Hideki -- Hideki Kato <mailto:[email protected]> _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
