Hi, You looks not using incremental-updating approach. This makes everything faster.
Hideki Goncalo Mendes Ferreira: <[email protected]>: >This reply is to both Erik and Petr, > >I was running a profile on the program just now. It spends about 90% >updating information to speed up the playout, these are captures and >liberties after play and the resulting 3x3 codified part of the board. >These are updated when needed, so about 4-8 intersections per play on >average. > >In the updating information part, the most costly is a recursive >function that counts liberties (it spends itself 33% of all time). > >It is in C in a modern PC, board size is 19x19. The heavy playout count >in the meanwhile was raised to 66 per sec/thread. I'm doing a lot of >optimizing and in the playouts part there is not much I can thin out >more. With these profiling results I'll attack the liberty counting >primitives next. You probably know some method more efficient than a >recursive search over the board surface. > >Gonçalo > >On 15/10/2015 00:43, Erik van der Werf wrote: >> I don't know, what language are you using? Did you do any >> optimizations? How many clock cycles does it take your program on >> average to make and undo a move (just counting the core board update)? >> >> BTW you didn't specify board size and hardware, so I assumed 19x19 and >> a modern PC. >> >> Erik >> >> On Thu, Oct 15, 2015 at 12:56 AM, Gonçalo Mendes Ferreira <[email protected]> >> wrote: >>> Really? I didn't mention it but it's uses MCTS-UCT with RAVE, progressive >>> pruning, mercy thresholds and max playout depth, etc. What could I be >>> missing that is that much of a boost in the playouts, in your experience? >>> >>> Gonçalo >>> >>> >>> On 14/10/2015 23:40, Erik van der Werf wrote: >>>> You should be able to do at least 50 times faster. >>>> >>>> Erik >>>> >>>> On Thu, Oct 15, 2015 at 12:27 AM, Gonçalo Mendes Ferreira <[email protected]> >>>> wrote: >>>>> Hi, I've been searching the mailing list archive but can't find an answer >>>>> to >>>>> this. >>>>> >>>>> What is currently the number of playouts per thread per second that the >>>>> best >>>>> programs can do, without using the GPU? >>>>> >>>>> I'm getting 2075 in light playouts and just 55 in heavy playouts. My >>>>> heavy >>>>> playouts use MoGo like patterns and are probability distributed, with >>>>> liberty/capture counts/etc only updated when needed, so it should be >>>>> pretty >>>>> efficient. >>>>> >>>>> What would be a good ballpark for this? >>>>> >>>>> Thank you, >>>>> Gonçalo F. > >_______________________________________________ >Computer-go mailing list >[email protected] >http://computer-go.org/mailman/listinfo/computer-go -- Hideki Kato <mailto:[email protected]> _______________________________________________ Computer-go mailing list [email protected] http://computer-go.org/mailman/listinfo/computer-go
