[Top][All Lists]

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

Re: [Bug-gnubg] bitfields

From: Joseph Heled
Subject: Re: [Bug-gnubg] bitfields
Date: Tue, 26 Nov 2002 11:22:07 +1300
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020829

Speaking of cache, something I forgot to warn everyone about after I changed the cache code. Make sure your .gnubgautorc has this (or larger)

set cache 65536

The old value of 8K is very small for the new cache. BTW, the 8k is the same as 32K for the new cache.


Jim Segrave wrote:
On Mon 25 Nov 2002 (19:57 +0000), Joern Thyssen wrote:

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

but Gary's point about the cost of cache misses is well taken. If the
evalcontexts are actually pointers/indices of a list of contexts, then
that list is unlikely to exceed a memory page - 4K bytes on the x86
architechture, so you could index some 400 different contexts in one
page. That page, if it's refererenced often, will be pretty much
locked into the working set of the process. Whether or not the smaller
storage for data will also bring about more locality of reference is a
much harder question. The very fact that there is a substantial cache
of previous evaluations suggests that there will be a lot of page
faulting going on at runtime. Maybe I should do some digging to see
how much info I can get on paging activity for gnubg run with
different cache sizes. That, combined with more stats on cache element
sizes would probably tell if there's any real profit to be made with
such a scheme.

reply via email to

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