[Computer-go] Direct DX11 and graphics cards for cheaper simulation

Bojun Huang huang_b_j at 163.com
Tue Jun 7 09:07:25 PDT 2011


Thank you very much for your explainations, it's very interesting to know the logarithmic growth and linear loss for SMP systems (which implies that the benefit from adding more cores would quickly disappear in large-scale systems)
 
btw, there was an expression error in my last email, I actually want to say "most strong programs trade off the playout speed against the playout quality". I think I've got your idea, the quality of simulation is much more important :-)
 
Thanks,
Bojun
 
>
> 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:hideki_katoh at ybb.ne.jp>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20110608/5827ed25/attachment.html>


More information about the Computer-go mailing list