Author: William Penn
Date: 20:39:57 03/11/04
Go up one level in this thread
On March 11, 2004 at 11:16:41, Robert Hyatt wrote:
>On March 11, 2004 at 01:26:31, William Penn wrote:
>
>>>>I only suggest reduced hash size in situations where tablebase access is
>>>>extremely heavy. There's no point to it otherwise, except I've noticed that
>>>>smaller hash size spits out analysis "legs" quicker. {Leg=analysis completed at
>>>>a particular ply level} Big hash size takes longer to finish the calculations at
>>>>a particular ply level.
>>>
>>>Then you have something broken. If bigger has slows the program down when
>>>tablebases are not accessed, something is wrong.. And since they are not
>>>accessed in most positions, bigger hash should generally always be better.
>>
>>Note that I'm running in infinite analysis mode for long periods of time,
>>usually several hours to analyze each position.
>>
>>Bigger hash lengthens the legs. I define a leg as completion of analysis at a
>>particular ply level. After completion of a leg, the analysis is spit out for
>>the user to see as text in the engine window. The more hash, then generally the
>>longer the time used for calculating each leg, the difference being that the
>>analysis goes a little deeper with more hash (apparently) with the Shredder 8
>>engine. The program speed as indicated by kN/s isn't slowed down a lot, but is
>>always a little less with larger hash.
>
>Here you have a poor definition of "bigger hash is worse".
>
>Hash can do two things:
>
>(1) make the search go faster to a specific depth. Generally, the bigger the
>hash table, the faster the program reaches a specific depth. You are us makeing
>this metric.
>
>(2) make the search at a specific depth more accurate. Which sometimes means
>the time to the same depth will be slower, but then the score is more accurate.
>You are ignoring this case.
>
>The longer the search time limit, the more important bigger hash sizes are. And
>this is _not_ guesswork. It's been proven over and over and over with
>testing...
We're perhaps talking about different things, and I haven't made myself clear:
Partly... What I'm interested in is getting the program to spit out analysis
into the real world in text form (into the engine window) where I can see it at
reasonable intervals. When analyzing for several hours in infinite analysis
mode, this can be a problem. Typically those intervals are perhaps about 1 hour,
2 hours, 4 hours etc if I use 512MB hash. Then if I switch to 768MB hash they
are typically more like 1 hour, 3 hours, 9 hours so they're longer in-between.
If I switch to smaller hash then they are usually more frequent. This is
important for scheduling my analyses. It is better to have the intervals (which
I also call "legs") smaller so I will have convenient points to stop the ongoing
analysis. If I have to wait for 10-20 hours for the next leg to complete, that's
usually too much time & trouble.
>>
>>>add another gig. Now your 512mb hash will work just fine... leaving over 1gig
>>>for the filesystem cache...
>>
>>I already have the maximum, 1G for this box. I'm not convinced (have no faith)
>>that the Windows XP op system would use more RAM advantageously. I'd have to see
>>it to believe it.
>>WP
>
>XP will use 4 gigs just fine. From experience...
XP will, but this Compaq Presario's specs say 1GB maximum. There's only two
sockets for RAM strips, and insofar as I'm aware 512MB is the biggest strip
available for it. Thus it's limited to 2 x 512MB = 1GB total.
WP
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.