Author: Christophe Theron
Date: 09:24:15 05/30/03
Go up one level in this thread
On May 29, 2003 at 02:44:59, Uri Blass wrote:
>On May 27, 2003 at 18:31:00, Christophe Theron wrote:
>
>>On May 27, 2003 at 03:16:00, Johan de Koning wrote:
>>
>>>On May 27, 2003 at 00:26:14, Christophe Theron wrote:
>>>
>>>>On May 26, 2003 at 11:22:09, Kurt Utzinger wrote:
>>>>
>>>>>On May 26, 2003 at 02:40:49, Andre van Ark wrote:
>>>>>
>>>>>>On May 26, 2003 at 02:06:37, Heinz-Josef Schumacher wrote:
>>>>>>
>>>>>>>>If you want my opinion it doesn't make any sense. Or I need a good explanation,
>>>>>>>>and some evidence.
>>>>>>>
>>>>>>>Exact my opinion! This rumour is in Germany in many heads, but without any
>>>>>>>evidence! More than 32 MB hash tables perhaps not useful for the King, but not
>>>>>>>bad! People had only misunderstood an old statement by Johan.
>>>>>>
>>>>>>Good day,
>>>>>>
>>>>>>32 MB is being used because Johan used in Leiden 30 MB.
>>>>>>
>>>>>>Kind regards,
>>>>>>Andre van Ark
>>>>>
>>>>> From own [old] tests under CM9-GUI in the analysis mode, I can remember
>>>>> that some positions could not be solved at all or not within reasonable
>>>>> time if hash tables were set higher than 32 MB hash. This may however be
>>>>> no longer a problem after the second patch has been released [I have
>>>>> however not investigated this]. And as Andre stated: Johan de Koning does
>>>>> not seem to use more than 32 MB hash and there must be some reason for that.
>>>>> Kurt
>>>>
>>>>The only reason I can think about is that there is some bug in The King hash
>>>>table management. Or some strange design decision. That's what you say suggests
>>>>to me, but I must add immediately that given the quality of Johan's work I don't
>>>>really believe that it is the case.
>>>
>>>A clearing delay you mentioned in another post was actually an issue with
>>>CM8000. But it was solved in the final patch (TK 3.12d). More importantly, it
>>>was a problem only with large TT *and* extremely fast time conrols.
>>
>>
>>
>>Yes I had the same delay before each search in a previous version of Tiger and I
>>agree that it would have hurt only at very fast time controls.
>>
>>So I guessed that it could not be the reason here.
>>
>>BTW I fixed it by adding a "generation counter" in every HT entry. So now I do
>>not need to clear the hash table anymore and the delay has totally disappeared.
>
>How many bits do you use in the generation counter?
>
>It may reduce the number of positions that you can use for a fixed size of hash
>tables but I guess that this problem is not very important and the advantage of
>using hash hits from previous generations for better order of moves even if you
>cannot trust the score is bigger.
>
>Uri
Yes and whilst adding this counter I have also found some ways to reduce the
amount of data I needed to store in the hash table, so I do not need more bytes
per entry than in the previous version.
So it's definitely a gain, particularly at very fast time controls (for example
I can use 384Mb of hash table even if Tiger is playing all the game in one
minute).
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.