bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Feature Request: Gnu to use rollouts for playing


From: Christian Anthon
Subject: Re: [Bug-gnubg] Feature Request: Gnu to use rollouts for playing
Date: Fri, 21 Aug 2009 23:32:32 +0200

Can you check the speed of the threaded/non-threaded rollouts (say
0ply eval 6ply truncation).

Christian.

On Fri, Aug 21, 2009 at 6:54 PM, Ian Shaw<address@hidden> wrote:
>
>
>> -----Original Message-----
>> From: Christian Anthon [mailto:address@hidden
>> Sent: 20 August 2009 07:28
>> To: Ian Shaw
>> Cc: address@hidden
>> Subject: Re: [Bug-gnubg] Feature Request: Gnu to use rollouts
>> for playing
>>
>> Most of the code is already in place. Things to consider:
>>
>> a) move filter - i.e. which positions to roll out
>
> I would expect to be able to specify these, possibly by loading a .rol
> file.
>
>> b) using GNURoller for plays and cubes in rollouts
>
> I have to think about this some more. In theory, why not? However, I do
> wonder whether it is equivalent to a normal rollout of certain settings.
> As I said, I haven't considered this.
>
>> c) efficiency of the current mt code for fast games in roll
>> outs - we lock all threads during accounting
>
> I'm not up with the mt. Isn't it only active in rollouts? It might be
> worth investigating whether you can multithread at the level of the nn
> evaluation of a single position, which with all those SSE calls surely
> takes up the most time. This would speed up play, analyses and rollouts
> to the same degree. You'd have to get an opinion from the mt guru's as
> to whether this is feasible and wouldn't incur too much overhead.
>
>> d) variance reduction - my limited experience tells me that
>> variance/time is more or less independent of turning it
>> on/off for 0 ply rollouts
>>
> I've just run a simple test on a single position using a 0 ply rollout.
> Without VR I recorded 589 moves in 1 minute; with VR it was 34 moves.
>
> It stands to reason that VR would slow things down. With no VR gnubg
> only needs to evaluate the actual roll. For VR, gnubg must evaluate the
> outcome all possible rolls to see how lucky the actual roll was compared
> to the others. This must be roughly equivalent to a 1-ply lookahead in
> cost.
>
> On a 1-ply rollout, the difference is less pronounced: 21 trials in 1
> minute with VR and 30 without VR. I suppose this is the effect of
> caching.
>
> -- Ian
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]