Author: Robert Hyatt
Date: 09:47:07 12/03/05
Go up one level in this thread
On December 03, 2005 at 09:48:12, Matthew Hull wrote: >On December 02, 2005 at 23:27:41, Robert Hyatt wrote: > >>On December 02, 2005 at 17:47:00, Tony Nichols wrote: >> >>>On December 02, 2005 at 17:21:59, Robert Hyatt wrote: >>> >>>>It is time to stop this now. The above is utter nonsense. We don't "search" >>>>hash tables. Larger hash tables do not take longer to search, because we just >>>>don't search them. We randomly probe into them and either hit or miss, so the >>>>size has absolutely no effect other than larger sizes hold more information >>>>without requiring that older data be overwritten sooner. >>>> >>>>You are quoting nonsense... >>> >>> >>>Hello, >>> >>> Is it safe to assume that you can't have too much hash? I mean, as long as you >>>have the ram. >>>Regards >>>Tony >> >> >>pretty much. Beyond some point additional hash will not help. But to see how >>it helps, set it to something like 384K (yes 384 k bytes) and run a position for >>say 10 minutes. Record the highest depth reached and the time to reach that >>depth. Double the hash and re-run. Keep doing this until it doesn't get any >>faster. You just reached the max needed for the 10 minute search time (10 >>minutes was just a number, pick anything you want). You will see significant >>speed improvements at first, but they begin to flatten out and eventually >>doubling the hash doesn't change a thing any further. >> >>If a program clears hash between moves (most do not) then this can be a bigger >>issue with large hashes since they do take time to clear should that be >>needed... > > >Also, a very slight slowdown with a huge hash table can take effect if the >higher memory positions require addressing tricks to reach, which seems to be >especially true on i686 systems. At that point, the diminishing return of a >huge table is overtaken by the extra clock cycles needed for the high-memory >probe, resulting in a slightly perceptible performance hit. Yes it is possible that when total memory size goes beyond some value that we begin to see TLB thrashing, which adds extra memory accesses to each hash probe, to translate the virtual addresses to real. However, in general, bigger hash should always be better, up until you reach the point where there is very little overwriting, going beyond that might do nothing more than aggravating the TLB miss problem. I always run a series of positions with steadily increasing hash size to find the "sweet spot" beyond which performance doesn't get better or begins to drop off due to excessive TLB misses...
This page took 0.01 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.