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
these...
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.