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
