Computer Chess Club Archives




Subject: Re: The King "Leiden" - Chesstiger 15 "normal" Now 6,5 -8,5 90 min blitz

Author: Christophe Theron

Date: 15:31:00 05/27/03

Go up one level in this thread

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.

>And then there is hardware issues, causing random access to slow down with
>increasing access range. That's highly dependant of the hardware, so I'm not
>going to even try to make a statement about it. Except that I'm convinced it is
>about a few percent at the very most.

Yes, I have seen that as well, but in my experience the slowdown is always
compensated by the search speedup. Unless you use very fast time controls, once

>But both issues do not apply here.
>And I'll have to agree with you that some bug is pretty unlikely. :-)

That's definitely not your style. :)

>>Anyway maybe it would be better if Johan could tell us what to do (and if
>>possible, why).
>Be happy (because then you will be happy)!

I'm glad to see you posting here.

In music, silence is valuable only because there are notes around it.


This page took 0.01 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.