Re: [Bug-gnubg] bitfields

[Jim Segrave]

On Mon 25 Nov 2002 (11:47 -0500), Gary Wong wrote:
> On Mon, Nov 25, 2002 at 03:10:06PM +0100, W.Stroop wrote:
> > I just figured out that single bitfields are using 2 more instructions then
> > no bitfields. Suppose one has a struct of 8  single bitfields the loss is 16
> > instructions.
> > If this is used 10.000 times you lose 160.000 instructions.
> 
> Twenty years ago, that would have been a big deal.  Today, it means
> virtually nothing -- arithmetical instructions are extremely cheap on
> modern hardware.  The major expense is memory access, largely because
> of the possibility of cache misses.  It might not be too much of an
> exaggeration to say that in many cases, arithmetic and logic
> instructions execute for free, since with intelligent scheduling, deep
> pipelines and wide superscalar issues, they will often complete before
> the next data fetch is available.
> 
> The reason we use bitfields in the evalcontexts and rolloutcontexts is
> because there are several in each evalsetup, and almost all
> moverecords contain one or more evalsetups.  Before we started storing
> analysis, there were no bitfields anywhere; but once we added
> evalsetups in the moverecords, we calculated that converting the
> appropriate members to bitfields led to significant memory savings.
> (And it might well turn out that this memory savings yields a speed
> win in the end -- notice that eliminating just one page fault will
> save you far more time than 160,000 instructions.)

This will seem dumb, but why do we save evalcontexts with moverecords?

Assuming (which may not be true) that there are relatively few
different evalcontexts active during any run of gnubg, then you could
replace storing the contexts with storing simply an index into a table
of pointers to copies of the setups, which would make the storage
requirements even smaller (and makes comparing setups and contexts
even faster), for what that might be worth.


-- 
Jim Segrave           address@hidden