Author: Richard Pijl
Date: 11:20:51 03/09/04
Go up one level in this thread
On March 09, 2004 at 13:14:35, Mike Hood wrote: >On March 08, 2004 at 23:49:58, William Penn wrote: > >>Pretty simple. Reduce hash size. That's the only thing I've found to have a >>significant effect when tablebase access starts to churn the hard drive >>constantly. Engine speed (kN/s) falls dramatically at that point, perhaps to 10% >>or less of normal speed, and never recovers. However using smaller hash size >>appears to fix this problem. > ><-- snip --> > >I understand what you're saying. Don't fill up all the available memory for hash >tables. Leave enough memory for Windows to use as file cache, so that the >tablebase files are in memory. Right? > >If the code is wriiten efficiently, this method of yours shouldn't bring an >improvement, and it might even make things worse. Maybe someone can comment on >this who knows more about the tablebase access code. Once a tablebase access has >been carried out, the result of the tablebase lookup should be stored in the >hash tables. The next time the same position is needed, the chess program >doesn't need another tablebase lookup, because the result is already in the hash >tables. The space needed for a stored position in the hash tables is less than >the blocks of data needed for a chunk of the tablebase file in the system cache, >so the hash table storage should be more efficient than the system cache. > >In a simple position with only a few possible transitions to a tablebase >position the disk accesses should cease completely within a few seconds. This is >the theory, but it isn't backed up by my observations. What's wrong? Even though you think there are a few possibilities, the search will find a lot more. Only positions with very few pieces may result in few disk accesses. Another thing that you should be aware of when ignoring the windows or egtb cache is that you're getting more than just the bytes you need during a single disk access. The disk/windows will fetch a whole block of data. Chances are that you will need more bytes in that block of data when examining other positions during the search. Ignoring the disk cache would mean an additional disk access here, where the position you're looking for could already be in the disk cache. Another reason is that the hashtable might refuse to store egtb entries because there are more valuable entries already there. Knps will go down, but reached search depth might go up... Richard.
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.