Author: Michael P. Nance Sr.
Date: 13:54:58 09/01/03
Go up one level in this thread
On September 01, 2003 at 14:23:51, Uri Blass wrote: >On September 01, 2003 at 13:20:48, Michael P. Nance Sr. wrote: > >>On August 31, 2003 at 21:18:58, Ross Boyd wrote: >> >>>On August 31, 2003 at 19:44:28, William Penn wrote: >>> >>>>The more hash I allocate, the slower the kN/s speed. Thus 4MB (the minimum) is >>>>the fastest in my tests, typically about 450kN/s. If I increase that to say >>>>256MB hash, the speed slows down to about 400kN/s. The more I increase hash, the >>>>slower the kN/s speed. >>>> >>>>The kN/s speed peaks, then eventually starts to decrease. How long this takes >>>>depends on the amount of hash. However in my tests, the long term speed >>>>advantage of bigger hash never catches up with the long term speed obtained with >>>>smaller hash. Thus I don't see any advantage whatsoever to using a hash table! >>>>The opposite seems to be true!? >>>> >>>>I'm using the Shredder7 GUI, Shredder 7.04 UCI engine, AMD XP Athlon 2400+/640MB >>>>RAM (608MB available). The GUI says the maximum I can allocate to hash is about >>>>455MB, so I'm not near the limit. Of course I'm using fairly common practical >>>>positions for these tests in Infinite Analysis mode, and the above indicated >>>>results are typical. >>>> >>>>I get very similar results running Shreddermarks with different size hash. The >>>>more hash, the lower the Shreddermark and corresponding kN/s. >>>> >>>>Now, will someone please refute this, or explain what I'm missing or >>>>overlooking? Thanks! >>>>WP >>> >>>Increasing the hash size will tend to lower the NPS in most engines. >>> >>>Its kind of hard to explain why this is so... but I'll try. When an engine gets >>>a hit in the hashtable it often cuts short the amount of exhaustive quiescence >>>searching where NPS tends to go high. Nearer the root there is generally more >>>overhead involved, with for example, more sophisticated move ordering etc... >>>whereas the move ordering at the QS tends to be cruder and hence faster. >>> >>>Anyway, its not a bad thing.... >>> >>>What is more important is the total number of nodes visited to get to a certain >>>depth. You will see that increasing hash size will tend to reduce the tree... >>>and therefore (even though NPS drops slightly) the actual time taken to get to a >>>given depth is reduced (usually). >>> >>>Time how long Shredder takes to get to a given depth, and also the total nodes >>>visited, with various positions for two hash sizes. You'll see the true benefit >>>of increasing the hash size. >>> >>>If you turn off the hash altogether you'll see the NPS increase a lot... but its >>>not going to play stronger that's for sure... >>> >>>So, NPS is not a measure of strength. Really, its only useful for comparison >>>purposes of the same engine with the same hash size on 2 different PCs. >>> >>>Hope this makes sense... >>> >>>Ross >> >>I will tell You this,when I demisish the Hash,(32,64,128,ect),I get beat. When I >>go "FULL THROTTLE",or optimise the Hash,(819), I usually beat the same Box and >>Program that I couldn't beat with a lower Hash setting.>>>>Mike > >I am not surprised. >If you give your program a big hash table and another application is running the >big hash tables is too much and it needs to read from the hard disk so it may >become very slow. > >I suggest not to give your program more than 1/2 of the RAM of your machine. >The possible advantage of few elo points is not enough to complensate for the >risk. > >You may even decide not to give more than 1/4 of the RAM of your machine and >still the program play at almost optimal strength. > >Uri Thanks Uri,I will get it a try. Using and playing with the Programs is a learning experience and One should play around until You find the "SWEET SPOT".>>>>Mike
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.