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 <mahrgel...@gmail.com> 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 <mahrgel...@gmail.com>:
>
> 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 <ben.el...@softweyr.co.uk>:
>>
>> 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 <
>>> jason.james.ho...@gmail.com> 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é" <alvaro.be...@gmail.com>
>>>> 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 <ben.el...@softweyr.co.uk>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
>>>>>> <mahrgel...@gmail.com>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 <hjohn...@evc.net>:
>>>>>>>
>>>>>>> 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
>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>>
>
> _______________________________________________
> 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
