This is absolutely correct.syzygy wrote:You removed my statement that it is the nps drop that hurts.Dirt wrote:No. For an extreme example, hash bigger than main memory will probably hurt.syzygy wrote:The only reason why bigger hash might not gain is that hash is already big enough (for a given test).
Hash bigger than main memory will lead to a very substantial nps drop and hurts for that reason and only for that reason.
Again: correct for nps drop by looking only at total nodes searched, and any disadvantage of bigger hash disappears. The one and only disadvantage of bigger hash is the nps drop.
Enabling large pages (i.e. make proper use of the hardware) significantly reduces the nps drop.
I would add that what most of these tests are measuring is hardware specific. Change the hardware and the end results of the test changes, sometimes dramatically. i.e. The measurement(s) is(are) NOT solely a function of the software.
HGM is correct that the leaf nodes are almost worthless. A huge fraction of them will never be seen again except on the next iteration of the same branch of the tree. i.e. most are highly local to that part of the tree. Any time insufficient TT space is available these entries will be overwritten before they can be of much use.
I believe that the cache entries in most programs are too small. They don't contain enough information for a replacement algorithm to replace only the least effective entry in a cache bucket. This isn't much of a problem if there is only one entry per cache bucket, but then this is by far, the least effective bucket size, so this only pertains to TTs with multiple entries per bucket.
The point of any replacement algorithm is to ensure that the entries that are kept provide the maximum reduction in time to depth. This, to some extent, is related to the size of the searched tree, which can be affected by cut-offs, bound changes, and move ordering.
Knowing things like, is the position the cache entry represents still possible given the current board position, how long an entry has been in the cache, how many times has it been referenced, how many times has it caused a cutoff/ bound change or suggested the next move to search are import when considering replacing an entry.
Making the TT entries large enough to hold such information, even if only for testing purposes, would seem to be a good first step in being able to measure how well a replacement algorithm is performing. Once direct and detailed measurements of TT performance can be made, replacement algorithms can be directly compared. Only the data that is vital to improved TT performance need be retained once a replacement algorithm has been decided upon.
For programs like Komodo, SF, and Houdini this would seem to be a no brainer. For lesser programs that are just implementing a TT or for those that are dissatisfied with their current TT performance this would also seem like a good use of time.
Regards,
Forrest