Author: Dieter Buerssner
Date: 12:55:27 10/20/02
Go up one level in this thread
On October 20, 2002 at 15:14:58, Christophe Theron wrote: >On the other hand, using more hash table always help, even at bullet time >controls. This all sounds very logical. There may be some subtle cases. For example, I would say, that for my engine the same is true. But, when reaching deep endgames, slightly different things can happen. Until very recently, I only had a rather outdated computer. I had seen, that giving less hash can speed up deep endgames with many TB-accesses significantly. The reason is easy to understand: The OS will use the unused memory for disk cache (under Linux and under Windows). The OS will cache TB positions in compressed form, and under many circumstances, this can be more efficient, than the Nalimov caching (because it can obviously cache more positions with the same space). Now I have a more modern computer, and I see something similar. Often, when analyzing deep endgame positions, giving (say) 150 MB of RAM to the OS can speed things up. I see, that the OS cache often rises over 100 MB. This would be enough, to keep all KRPKR positions in cache (and in many positions, this is probably the by far mostly accessed TB). Uncompressed, almost an order of magnitude more is needed. I see some more strange things. One tester of my engine with very decent hardware, gets only extremely bad nodes/s in many deep endgames - and it is certainly a cause of some losses on ICC. Some numbers: I have seen 25 kn/s on his computer many times. On my old computer (with slower HD, less memory, etc.) in comparable situations, I hardly ever saw under 100 kn/s. Primitive errors (giving too much hash, etc.) can be excluded. Regards, Dieter
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.