[Top][All Lists]
[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!
- Re: [Bug-gnubg] Bitfields, (continued)
[Bug-gnubg] Bitfields, W.Stroop, 2002/11/25
[Bug-gnubg] bitfields, W.Stroop, 2002/11/25
- Re: [Bug-gnubg] bitfields, Gary Wong, 2002/11/25
- Re: [Bug-gnubg] bitfields, Jim Segrave, 2002/11/25
- Re: [Bug-gnubg] bitfields, Jim Segrave, 2002/11/25
- Re: [Bug-gnubg] bitfields, Gary Wong, 2002/11/25
- Re: [Bug-gnubg] bitfields, Jim Segrave, 2002/11/25
- Re: [Bug-gnubg] bitfields,
Joern Thyssen <=
- Re: [Bug-gnubg] bitfields, Jim Segrave, 2002/11/25
- Re: [Bug-gnubg] bitfields, Joseph Heled, 2002/11/25
RE: [Bug-gnubg] bitfields, Øystein Johansen, 2002/11/25