bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Tutor Mode/Hint question


From: Jim Segrave
Subject: Re: [Bug-gnubg] Tutor Mode/Hint question
Date: Fri, 10 Jan 2003 17:13:20 +0100
User-agent: Mutt/1.4i

On Fri 10 Jan 2003 (16:02 +0100), Jim Segrave wrote:
> On Fri 10 Jan 2003 (13:31 +0000), Joern Thyssen wrote:
> > 
> > It's a known problem that tutor mode re-evaluates the moves a second
> > time. It's a general problem with the analysis code, so the same problem
> > exists if you re-analyse a match.
> > 
> > It's on my TODO list to fix this, but unfortunately it's not entirely
> > trivial, because we only save the highest evaluation for each move, but
> > the move filters requires us to evaluate all moves on 0-ply, then some
> > of those on 1-ply, the some of those on 2-ply etc etc. For example, a
> > sample chequerplay decision has 4 moves evaluated on 2-ply, another 6
> > moves on 1-ply, and the remaining 37 moves on 0-ply. Assume I want to
> > re-analyse this move (possibly with another move filter). How should I
> > do this? The biggest problem is that move filters involves comparing
> > equities, but you cannot compare 2-ply equities with 1-ply equities as
> > this is like comparing oranges and apples :-)
> > 
> > I've a number of strategies for this. Two main points are:
> > 
> > (a) avoid re-doing any, possibly expensive, re-evaluations
> > (b) consistent results, i.e., no difference between re-analysis of a
> >     move (possibly with a new move filter) and first analysis with a given
> >     move filter.
> > 
> > Unfortunately (a) is orthogonal to (b), so we have to decide which
> > approach to take. As a exact-science scientist I prefer that (b) is
> > fulfilled, however, as an impatient user I prefer that (a) is
> > fulfilled.
> 
> Cacheing?
> 
> Suppose that we cache evaluations with keys of positionID and no. of
> plies only (where a rollout evaluation could be given an arbitrarily
> large no of plies so that it's always taken as the best one). Entries
> could be reused in LRU order, so recent evaluations are kept as long
> as possible.
> 
> Any change made to move filters or other settings which could affect
> an evaluation invalidates all cache entries. The cache could have
> associated with it a copy of the relevant settings which apply to its
> contents. This need not be checked on every cache access, instead it
> needs only to be checked when a command is executed that may lead to
> evaluations being done - Evaluate, Analyse, Hint, Rollout would cover
> it. 
> 
> For things like tutor mode or use of the hint window, I would expect
> that for reasonable cache sizes, that the delay would be minimal to
> re-analyse, as the evaluation results for all the intermediate
> calculations would still all be in the cache. 
> 
> I wouldn't expect to be able to change the analysis settings and not
> have to wait while a move, match, or game is re-evaluated seems
> reasonable.
> 
> How big does the cache have to be? I'm running a profiler on a 376
> move 7 game match, which will give me call counts. From that I should
> be able to get an average no. of evaluations/move. If I assume
> (hand-waving mode on) that the worst case is 20 to 50 times as many
> evaluations as an average one, I'll have some estimates.

Ok - analyzing this match shows that 
AnalyzeMove was called 376 times - no surprise there.
NeuralNetEvaluate was called 8413251 times, or an average of 22375
times/move. So a worst case from my wild guess is that you need a
cache of perhaps 450000 entries to pretty much keep everything. 
It looks to me from watching the memory size while analyzing with
various cache sizes that this is on the order of 20Mb of RAM for a
cache this size.

-- 
Jim Segrave           address@hidden




reply via email to

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