Author: Richard Pijl
Date: 04:22:43 03/09/04
Go up one level in this thread
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. > >For example my computer has 1G RAM installed. I can run Shredder 8 with 768MB >hash normally, although I often use 512MB which the op system prefers a bit >more. Now one would think that 512MB hash would be OK in any situation with 1G >RAM, but not so. It's too much hash when tablebase access starts to crank up >heavy in endgame situations. At that point, reducing hash size to 256MB usually >fixes this problem, restoring engine speed to a reasonable kN/s. I haven't yet >found it necessary to goto 128MB hash. > >[Windows XP Home, Athlon XP 2400+/2.0GHz, 1G RAM] >WP I think this is a correct observation. You have to be aware that EGTB's will be cached in a lot of different way. In the Baron I store probed positions in the Hashtable, there is the EGTB cache where segments of uncompressed EGTB entries are stored, and the Windows cache where compressed chunks of EGTB's are stored. If no caching would take place, I would expect knps to drop to less than 1/100 of the speed during normal search (without EGTB's) as seek times of disks are still several ms. If 1 out of 10 innernodes would probe the EGTB's you would get no more than about 2-3 knps and that is very optimistic. It will probably be significantly less. Fortunately chess programs store, reuse or cache the done work in several ways, and with a different granularity. For one EGTB probe that results in a disk access Hashtables store 1 position, EGTB cache stores several positions (uncompressed) and the windows cache stores a large chunk of (compressed) data. The chance this data will be reused in a later probe is significant. The configuration I use for the Baron during ICC games or tournaments is that I have 400Mb of transposition hashtables and 64 MB of EGTB cache. Internal memory is 1 Gb. The Baron probes EGTB's in all inner nodes. In this configuration I saw the knps go _up_ in endgames, due to the saved cost in evaluation of leaf-nodes. I don't have SCSI disks. Just plain 7200rpm IDE disks (IBM Deskstar). The reason why I limit the hashtable to 400 Mb is a different one though. I still have Win2k prof as the OS. There the memoryaccess above 512Mb will not be cached, so chosing a hashtable size above 400Mb has a negative effect on regular search too. But for diskcache that is good enough ... 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.