simple ko checks are sufficient in random playouts ;) limit the number of moves to something reasonable (like 3 times the fields on the board) and you will catch that one in a billion games superko. This should save a fair amount of time. In any case... Your speed sounds reasonable. You can optimize it further later on, once you know what exactly you need from your board implementation. Have fun with your tree :)
My current implementation runs at 100k playouts 9x9 in 7 sec on an i7-3630, 8GB, but has a bit heavier playouts. (saving/capturing, mogo style 3x3 patterns, basic dead shapes, some fun about keeping/destroying eyes properly) Marc 2014-05-09 23:35 GMT+02:00 Ben Ellis <[email protected]>: > I've made a start on my first attempt at writing a go playing program > using the .NET framework, and with 1000 empty 9x9 random playouts I'm > getting the following benchmarks, > > Single Threaded (uses about 30% CPU) > VS DEBUG 64bit (with Debugger) - 266ms per 1000 playouts. > VS RELEASE 64bit - 182ms per 1000 playouts > > Thread Per Core (Uses 100% CPU) (Thread Per Core - 1 yielded similar > results) > VS DEBUG 64bit (with Debugger) - 154ms per 1000 playouts. > VS RELEASE 64bit - 111ms per 1000 playouts > > System Specifications: > Processor: Intel Core i7-4600U CPU @ 2.10Ghz > 8GB DDR3 RAM > > The random player won't play, > > - Positional super-ko moves (or optionally situational) > - Suicide moves > - Eye filling moves > > and continues to play until there are no good moves left (i.e. all empty > intersections are an eye, suicide or unplayable due to ko) > > Am I missing any other checks/features to the random play outs that would > normally be implemented? > > What sort of play out speeds are normal, should I spend any more > optimizing the random play outs before moving into a Monty-Carlo > implementation? > > Regards, > > Ben > > > On Wed, May 7, 2014 at 11:09 PM, Jason House > <[email protected]>wrote: > >> Simple ko checks are required in playouts. Advanced ko checks are >> typically restricted to inside the search tree. With simple ko checks, I've >> had playouts get stuck in a 3 ko cycle. Ko cycles can be caught with a >> maximum playout length. >> On May 7, 2014 10:46 AM, "Álvaro Begué" <[email protected]> wrote: >> >>> I believe you *have to* check for simple ko in playouts. Otherwise >>> you'll end up with infinite playouts quite easily. >>> >>> >>> >>> >>> >>> On Wed, May 7, 2014 at 9:09 AM, Ben Ellis <[email protected]>wrote: >>> >>>> All, >>>> >>>> When playing random playouts, do you (anyone) bother checking for >>>> KO or super KO? Does this have a negative impact on accuracy of the >>>> win:loss outcomes? >>>> >>>> Ben >>>> >>>> >>>> On Thu, May 1, 2014 at 4:52 PM, Marc Landgraf <[email protected]>wrote: >>>> >>>>> Now I feel stupid :( >>>>> Thanks... >>>>> So now I'm down to 126 on average with /O2 /Ot /favor:INTEL64 (+the >>>>> usual fluff) >>>>> This is still about 15% slower then mingw-w64, but this is just for >>>>> singlethreaded playouts. >>>>> And it looks like, that when using 4 threads on the same tree, this >>>>> gets compensated, and we arrive at pretty much the same speed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-05-01 15:36 GMT+02:00 Harald Johnsen <[email protected]>: >>>>> >>>>> Le 01/05/2014 13:00, Marc Landgraf a écrit : >>>>>> >>>>>> Hey, >>>>>>> I'm not talking about 20% speedloss here with VC++. >>>>>>> Just the times for 1000 empty playouts on 9x9, not using any sort of >>>>>>> multithreading: >>>>>>> VS debug configuration: 15257 >>>>>>> VS release config (optimized): 756 >>>>>>> C::B mingw-w64 no optimizations: 498 >>>>>>> C::B mingw-w64 -O3 -fexpensive-optimizations -march=corei7-avx: 108 >>>>>>> >>>>>>> This of course clearly looks as this is certainly my fault... But >>>>>>> right now I can't find what I'm doing wrong here... and so I have to >>>>>>> miss >>>>>>> out those handy VS-comfort features and continue with C::B + mingw-w64. >>>>>>> And the VS profiler results looks pretty much like what I got, when >>>>>>> I last used VerySleepy on my code compiled with mingw. No super drastic >>>>>>> bottlenecks just general slowness it seems. >>>>>>> Mingw-w64 makes it impossible to profile the code, but mingw has >>>>>>> performance issues as well for me, so I'm using it only when i need >>>>>>> profile >>>>>>> data (not as drastic as VC++, but about factor 3). >>>>>>> >>>>>>> >>>>>>> Are you doing any memory allocation or input/outputs ? If that's >>>>>> the case then you should not start the code with F5 but shift F5 from >>>>>> inside VS. >>>>>> >>>>>> hj. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Computer-go mailing list >>>>>> [email protected] >>>>>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Computer-go mailing list >>>>> [email protected] >>>>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Computer-go mailing list >>>> [email protected] >>>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >>>> >>> >>> >>> _______________________________________________ >>> Computer-go mailing list >>> [email protected] >>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >>> >> >> _______________________________________________ >> Computer-go mailing list >> [email protected] >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> > > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
