Oh no I actually agree with you. But I share concerns of Joona about the kind of algorithm to be used. He probably used root parallelization scheme like I just did. It scales almost perfectly on a cluster of 16 cpus nps wise. But then I realized this might not be as good as it seems because the different processors might not produce significantly different trees.. Infact at first I wrongly seeded the random number generator to time(NULL) which gave me almost the same tree in all the processors. Then I modified that to include the processor id and it starts producing different trees, but I still think there is lot of redundancy in there. If I still use the same exploration constant 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 ,not necessarily deeper. The improvement from a 16x more computing time (i.e shared tree) should be much more than the one I get by using this simple parallelization scheme. I am trying to introduce more selectivity by dividing UCTK by number of processors N (i.e UCTK / N). Does that sound reasonable ?
On Tue, Apr 5, 2011 at 3:25 AM, Gian-Carlo Pascutto <g...@sjeng.org> wrote: > Those were single processor tests. > > > > 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. > > > > > > *From:* computer-go-boun...@dvandva.org [mailto: > computer-go-boun...@dvandva.org] *On Behalf Of *Daniel Shawul > *Sent:* Tuesday, April 05, 2011 1:56 AM > > *To:* computer-go@dvandva.org > *Subject:* Re: [Computer-go] UCT parameters and application to other games > > > > Something I am not clear about is the algorithm used. Or is it just a test > on a single > > processor version by giving it more time to search? If the tree is not > shared as in the 'root parallelization' > scheme, I have doubts if it can search 'deeper' even though nps scales > almost perfectly. > By deeper ,I mean more expansion to the best moves. Since the processors > are not searching the same tree , > it seems to me the search in parallel is wider (more alternatives) but not > necessarily deeper searched. > Or is this taken care of by using a lower exploration constant (c) for the > parallel search in the hope that > it would fill the void introduced by adding more selectivity ? > > > On Mon, Mar 28, 2011 at 5:49 AM, Gian-Carlo Pascutto <g...@sjeng.org> > wrote: > > >However one of my early observations with Go programming has been > >that the speed is not a very big issue in this field (at least in lower > levels). > > >[...] > > >10x more processing power only gave around 100 extra elo points. > > > > > >Of course with heavy playouts and more fine tuned programs things can > >be very different... > > No. You probably have some other problem or bugs. See for example this > study: > > http://cgos.boardspace.net/study/13/index.html > > Leela Lite was using light playouts. The slope is a bit flatter than the > real program, but not much more so. You should get far more than 100 ELO > for > a 10x speedup. > > -- > GCP > > > _______________________________________________ > Computer-go mailing list > Computer-go@dvandva.org > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go > > > > _______________________________________________ > Computer-go mailing list > Computer-go@dvandva.org > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list Computer-go@dvandva.org http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
