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<[email protected]> wrote: > > >> -----Original Message----- >> From: Christian Anthon [mailto:[email protected]] >> Sent: 20 August 2009 07:28 >> To: Ian Shaw >> Cc: [email protected] >> 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 > _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
