Oh no I actually agree with you. But I share concerns of Joona about the kind of algorithm to be used. <div>He probably used root parallelization scheme like I just did. It scales almost perfectly on a cluster of 16 cpus nps wise.<div>
<div><div><div>But then I realized this might not be as good as it seems because the different processors might not produce</div><div>significantly different trees.. Infact at first I wrongly seeded the random number generator to time(NULL) which </div>
<div>gave me almost the same tree in all the processors. Then I modified that to include the processor id and it starts</div><div>producing different trees, but I still think there is lot of redundancy in there. If I still use the same exploration constant</div>
<div>UCTK all processors are going to explore more or less to the same depth. So the benefit will be a wider (i.e safer) search</div><div>,not necessarily deeper. The improvement from a 16x more computing time  (i.e shared tree) should be much more than the one I get</div>
<div>by using this simple parallelization scheme. I am trying to introduce more selectivity by dividing  UCTK by number of processors N </div><div>(i.e  UCTK / N). Does that sound reasonable ?</div><div><br><div class="gmail_quote">
On Tue, Apr 5, 2011 at 3:25 AM, Gian-Carlo Pascutto <span dir="ltr"><<a href="mailto:gcp@sjeng.org">gcp@sjeng.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="NL-BE" link="blue" vlink="purple"><div><p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;color:#1F497D">Those were single processor tests.</span></p><p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;color:#1F497D">I wanted to point out that your “speed is not a very big issue” guess is wrong and that the heaviness of the playouts doesn’t change that either. Strength scales strongly with playouts/speed. So something is limiting your result, and a bad parallelization can very well be it.</span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;color:#1F497D"> </span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt">From:</span></b><span lang="EN-US" style="font-size:10.0pt"> <a href="mailto:computer-go-bounces@dvandva.org" target="_blank">computer-go-bounces@dvandva.org</a> [mailto:<a href="mailto:computer-go-bounces@dvandva.org" target="_blank">computer-go-bounces@dvandva.org</a>] <b>On Behalf Of </b>Daniel Shawul<br>
<b>Sent:</b> Tuesday, April 05, 2011 1:56 AM</span></p><div class="im"><br><b>To:</b> <a href="mailto:computer-go@dvandva.org" target="_blank">computer-go@dvandva.org</a><br></div><div class="im"><b>Subject:</b> Re: [Computer-go] UCT parameters and application to other games</div>
<p></p></div></div><p class="MsoNormal"><span lang="EN-GB"> </span></p><p class="MsoNormal" style="margin-bottom:12.0pt">Something I am not clear about is the algorithm used. Or is it just a test on a single</p><div><div>
</div><div class="h5"><br>processor version by giving it more time to search?  If the tree is not shared as in the 'root parallelization' <br>scheme, I have doubts if it can search 'deeper' even though nps scales almost perfectly.<br>
By deeper ,I mean more expansion to the best moves. Since the  processors are not searching the same tree , <br>it seems to me the search in parallel is wider (more alternatives) but not necessarily deeper searched.<br>Or is this taken care of by using a lower exploration constant (c) for the parallel search in the hope that<br>
it would fill the void introduced by adding more selectivity ?<br> </div></div><p></p><div><div></div><div class="h5"><div><p class="MsoNormal">On Mon, Mar 28, 2011 at 5:49 AM, Gian-Carlo Pascutto <<a href="mailto:gcp@sjeng.org" target="_blank">gcp@sjeng.org</a>> wrote:</p>
<div><p class="MsoNormal">>However one of my early observations with Go programming has been<br>>that the speed is not a very big issue in this field (at least in lower<br>levels).</p></div><p class="MsoNormal">>[...]</p>
<div><p class="MsoNormal" style="margin-bottom:12.0pt">>10x more processing power only gave around 100 extra elo points.<br>><br>><br>>Of course with heavy playouts and more fine tuned programs things can<br>>be very different...</p>
</div><p class="MsoNormal">No. You probably have some other problem or bugs. See for example this<br>study:<br><br><a href="http://cgos.boardspace.net/study/13/index.html" target="_blank">http://cgos.boardspace.net/study/13/index.html</a><br>
<br>Leela Lite was using light playouts. The slope is a bit flatter than the<br>real program, but not much more so. You should get far more than 100 ELO for<br>a 10x speedup.<br><br>--<br><span style="color:#888888">GCP</span></p>
<div><div><p class="MsoNormal"><br>_______________________________________________<br>Computer-go mailing list<br><a href="mailto:Computer-go@dvandva.org" target="_blank">Computer-go@dvandva.org</a><br><a href="http://dvandva.org/cgi-bin/mailman/listinfo/computer-go" target="_blank">http://dvandva.org/cgi-bin/mailman/listinfo/computer-go</a></p>
</div></div></div><p class="MsoNormal"> </p></div></div></div></div></div><br>_______________________________________________<br>
Computer-go mailing list<br>
<a href="mailto:Computer-go@dvandva.org">Computer-go@dvandva.org</a><br>
<a href="http://dvandva.org/cgi-bin/mailman/listinfo/computer-go" target="_blank">http://dvandva.org/cgi-bin/mailman/listinfo/computer-go</a><br></blockquote></div><br></div></div></div></div></div>