This has been tested before, by me and others. The result then was that a 2
entry cache was better than either a single or 3 entry cache (all 3 using the
same amount of memory).
I expect the cache sizes used were relatively small, so this result might be
different for large caches.
Jon
Michael Petch wrote:
>
> 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" 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
>
_________________________________________________________________
Access your other email accounts and manage all your email from one place.
http://clk.atdmt.com/UKM/go/167688463/direct/01/
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
