Author: Brian Richardson
Date: 06:48:42 05/02/00
Go up one level in this thread
On May 01, 2000 at 23:36:30, Robert Hyatt wrote: [snip] >This is a well-known bug. If you use totally depth-prefered replacement, you >run into a big problem, in that the table (in a deep search) gets filled with >'deep positions' and the positions near the tips don't get stored. Yet they >are _critical_. My approach is the one used by Ken Thompson, that of using >two tables, one depth-prefered, one always-store. > >Probably the best way to compare two programs is to do the following: Pick a >position, and search (using the same hardware) for 300 seconds, while varying >the hash table for both from something very small, to something very big. For >each program, you will find a point where the improvement slope drops sharply >and levels off. We need to test a q-search prober vs a non-q-search prober. > >I can run the test for Crafty if you want... and can run from something tiny >up to 384M max... I have tested Tinker with q-search hashing and without. Tinker is 30+% faster with q-hash. However, note that Tinker has no SEE. I think this may have a lot to do with the effectiveness of q-hashing. I have also tested Tinker with single level depth replacement hash vs 2 level depth plus always replace. I only went 8-10 ply, but 2 level was typically 10% slower than single level (8-64MB sizes, and single level equal sum of both in 2 level). I recently recieved all the back ICCA issue and have been looking at the article on 2 level hash tables (don't recall specific issue) which showed only a 10% faster time for an 8-ply search. Of course, this was many years ago, and system architectures and cache performance characteristics are different. I will try to test again with much deeper searches.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.