bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] bitfields


From: Joern Thyssen
Subject: Re: [Bug-gnubg] bitfields
Date: Mon, 25 Nov 2002 19:57:45 +0000
User-agent: Mutt/1.4i

On Mon, Nov 25, 2002 at 08:05:52PM +0100, Jim Segrave wrote
> On Mon 25 Nov 2002 (13:25 -0500), Gary Wong wrote:
> > 
> > Perfectly true, we could do that.  I seem to remember discussing the
> > possibility of sharing evalcontexts with ref-counting semantics at the
> > time we implemented moverecords, but we must have decided against it
> > for one reason or another (presumably because the bookkeeping is
> > slightly annoying and error-prone; another reason is that evalcontexts
> > used to be smaller, comparable to the size of an integer/pointer,
> > which isn't true any more).  I get the impression that your suggestion
> > is to keep a copy of each evalcontext in a hash table even after it is
> > unreferenced, which does look more appealing now that rolloutcontexts
> > are significantly bigger than they used to be.
> 
> That sort of idea, yes. I haven't got any real design in mind, because
> I haven't looked closely enough at what's being done and how they are
> being used. I don't think there are that many evalcontexts live at any
> given time - 
> there are the ones created by initialisation, new ones
> when the startup file is read, and ones created by users changing
> settings. The cost of keeping a copy of each one and assigning it a
> small index should not be that large. But I don't know how often they
> are referenced for comparisions to know if there's really any profit
> in that. 
> 
> I mistakenly thought this was already being done when I glanced at the
> code in eval.c, but I see that that's keeping different information in
> the evalcache structs. 

We actually end up storing quite a few evalcontexts. 

For example, each cube decision requires 1 evalsetup (i.e., 6
evalcontexts) and each move decision requires the number of moves saved
times 1 evalsetup. 

We may end up storing many identical evalcontexts... Of course, each
evalcontext is approximately 10 bytes , so we can easily store 1M+ of
these...

Jørn

-- 
Joern Thyssen, PhD
Vendsysselgade 3, 3., DK-9000 Aalborg, Denmark
+45 9813 2791 (private) / +45 2818 0183 (mobile) / +45 9633 7036 (work)
Note: new mobile number!




reply via email to

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