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

Reply via email to