Author: chandler yergin
Date: 14:11:32 12/03/05
Go up one level in this thread
On December 03, 2005 at 12:47:07, Robert Hyatt wrote: >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... I think that's what some of us meant when the thread started. That there is an Optimal amount of Hash based on available Ram of the Processor. I really don't understand all the confusion.
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.