Author: Christophe Theron
Date: 19:18:38 11/21/03
Go up one level in this thread
On November 21, 2003 at 18:18:47, K. Burcham wrote:
>
>ok so we are getting different info on this.
>some say "the more the better", such as Chris for the Tiger programs, and now
>Chessbase is saying the same as Chris.
>It seems Johan is not worried about his hash collisions and prefers to keep his
>hash small, even though some say use as much as possible without "swapping to
>the hard drive". Maybe Johan will up his advice for hash settings with 2 to
>three gig hardware, but it was not done with the release of CM 9000.
>of course Dann I am not talking about short blitz games.
>
>It seems that some are saying "keep collisions as low as possible" (chessbase
>and Chris), but Johan and yourself are saying that "Collisions are no big deal".
>
>http://www.chessbase.com/newsdetail.asp?newsid=1311
Collisions cause the same problem in every chess program I would say. I don't
think that Johan would say that collisions matter less to The King than to Chess
Tiger. And I guess that Johan would be also very happy to "keep collisions as
low as possible".
The advice "set your hash table to the greatest value that does not cause hard
disk swapping" applies to Chess Tiger. It does not matter what time control you
are using. You might be playing a bullet game, I still advise you to use as much
RAM as possible.
It is possible that this advice would not work for another chess program, for
example one that "clears" its hash table before it starts thinking. In this
case, clearing 1Gb of hash table when playing bullet games would lead the
program to use almost all its time for "clearing the hash table". Really dumb.
However, Chess Tiger does not have to clear its hash table, so you can give as
much as you want.
But, again, this is valid for Chess Tiger and it is NOT a general rule.
I fear that you will not get a simple, general picture about this problem. Every
program might come with its own advice. The reasons why programs differ in this
regard are:
* NPS: a program that looks at many positions per second is going to "fill" the
hash table faster. Actually "fill" is a very inaccurate word. People, when they
hear that word, start to wonder when the hash table is "full" (full means that
it stops working for them) and the problem is that a hash table is NEVER full
(always keeps on working no matter how "full" it is). Let's say that it will
have to replace more entries per second than a slower program, or in other words
it will have to forget more information per second than a slow searcher.
* Need to clear that HT at the beginning of the search (see above).
* Replacement scheme: some programmers think they have found smarter ways to
replace old entries, or smarter ways to avoid saturation. They will tend to
believe that their program needs less HT space to achieve the same performance
than their competitors...
* BUGS: some programs have pathological algorithms or are buggy. And in this
case giving the program more HT can actually make the program weaker!
* Design: some programs try to store a lot of information in every HT entry.
They will need for example 32 bytes per entry. Other programs are able to do
well by storing just 12 bytes per entry.
* Hardware architecture: on some computers, accessing really large amounts of
RAM in random order causes very odd performance degradations. The problem is
that the programmer cannot tell you in advance if this is going to be the case
on your computer...
In any case, I would say that no matter what the programmer says it is unfair to
give one program more HT size than its opponent just because "it needs more HT
to perform well" (it would be like giving a faster processor just because one
pretends that it has been designed for it). However it's OK to give one program
less HT size if the programmer advices you to.
Christophe
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.