Re: [Bug-gnubg] Bug: 14 point one-sidedrace databasewithmakebearoff.exe

[Joern Thyssen]

On Wed, Jan 12, 2005 at 09:01:59AM -0000, Ian Shaw wrote
> 
> > 
> > Actually the performance is worse using the databases as the 
> > I/O takes more time than a neural net evaluation.
> > 
> 
> I think this is true for playing games, but not necessarily so for
> rollouts. If we are doing cubeless rollouts we cab truncate at the
> one-sided database, thus saving a significant number of net
> evaluations. 

True.

> Maybe I'll try to benchmark this one day. (This
> truncation will also affect the standard error, but I'm not sure how
> or if this is factored into the reported SE.)

Suppose you reach a race position available from the
one-sided database with a win of, say, 65%. With no truncation the
rollout would continue to the bitter end, you would reach a result of
0% or 100%, but with an variance reduction term of +65% or -35%, so the
actual result plus the var red term gives back 65%. That is, this kind
of truncation does not affect the SE of the entire rollout. 

> Would it speed up the access to have incremental chunks of the
> database in separate files? E.g. one database for up to six points,
> another for the 7 to 10 points, and one each per point thereafter.

I don't think so. 

What is needed is some kind of efficient reading and caching of the
file. For example, in a 2-ply evaluation you may need several thousand
lookups in the database. However, many of the distributions needed are
read several times, so having those distributions cached could reduce
disk I/O a lot. 

Also it may be advantegeous to group the distributions so "close"
positions are "close" in the file. For example, in order to do a 1-ply
evaluation of a given position, you need all positions reachable within
one roll. If these were grouped together they could be read in one go
and the entire calculation could be performed without disk I/O. I don't
know if this is feasible. 

J?rn

pgpmYvTvYs2ih.pgp
Description: PGP signature