You can read about it here: http://hal.inria.fr/docs/00/12/15/16/PDF/RR-6062.pdf
And don't bother too much about your speed right now ;) You will see things different, once you have the bigger picture anyway. 2014-05-12 13:51 GMT+02:00 Ben Ellis <[email protected]>: > Marc, > > Managed to get mine down to 54ms per 1000 playouts, if I run 1 thread it > runs in 94ms (still looking for positional/situational superko for now). > > My CPU has 2 physical and 4 logical cores, when I use 2 threads it uses up > 50% of the CPU and runs in 55ms, and if I use 4 threads, it uses 100% CPU > and still runs in 55ms. > > I suspect either the logical cores aren't being fully utilized, and/or the > bottleneck is in memory access speed not CPU cycles, has anyone else run > into a similar situation when utilizing hyper-threading? > > I think I'll move onto implementing GTP and then monte-carlo so I can > track win/loss and accuracy, then try to adjust my random play outs to take > saving/capturing and identifying dead/alive groups into consideration. > > What are the mogo 3x3 style patterns you mentioned? > > Ben > > > On Fri, May 9, 2014 at 10:56 PM, Marc Landgraf <[email protected]>wrote: > >> oh, my benchmarked numbers are singlethreaded... quad threaded it >> actually runs about 3-3.5 times as fast >> >> >> 2014-05-09 23:55 GMT+02:00 Marc Landgraf <[email protected]>: >> >> 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 >> > > > _______________________________________________ > 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
