Wonder how the cache would perform if we got rid of the second position per key (All the memcmps, the primary and secondary swap can be removed) and then increase the cache size. Rather trivial change, but until now I wonder how much would be saved without the secondary entry comparisons/swapping. There would be added cost of replacing positions when the an entry for an existing hashkey gets replaced. In theory part of this can be mitigated by increasing the cache size.
On 03/09/09 7:17 AM, "Jonathan Kinsey" <[email protected]> wrote: > The cache uses a hash function to map the position onto a cache entry, there > is > every chance of several positions mapping to the same position (the cache > stores > 2 positions per entry to minimise this). > > The reason things get better even when the cache is bigger than the total > number > of evaluations is there will be less collisions in the cache. There is a > #define you can set and then a command to get the cache statistics (lookups, > hits). > > It might be possible to improve the hash function (GetHashKey), but it does > seem > to do quite a good job. > > Jon
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
