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

[Ian Shaw]

> -----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