Author: Christophe Theron
Date: 18:04:53 05/28/03
Go up one level in this thread
On May 28, 2003 at 20:04:49, Johan de Koning 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.
>
>That would work.
>Since I insist on clearing at every search (predictability!), I use only 1 bit
>per entry. In a separate small array of course, else it would still be equally
>slow.
I had not even thought to do it this way! :)
Your insistance on predictability probably comes from the obsession to be able
to reproduce problems in order to fix them. An obsession I share with you.
That's the only way to go if one wants to produce quality software.
However at some point my will to get always more performance from the engine
just won. And I decided to keep the hash table between searches (but I confess I
do not trust completely the hash table content, thus limiting some potential
errors).
>[snip]
>
>>I'm glad to see you posting here.
>
>I'll take that as a compliment. :-)
>But I find it rather exhausting since it is very hard to stop posting. Next time
>at Leiden I'll let Tiger win again, just to generate a little less attention for
>The King. Though I did definitly enjoy the countless congratulations!
Your engine has always got a very positive image. I have not tested your latest
versions (in an attempt to continue to introduce genuine chess knowledge into my
engine, not anti-computer chess knowledge), but I remember the time when I used
to let Tiger get slaughtered by CM4000 (The King 2.61 IIRC).
There are things you do in your engine that I have no idea how you do them. But
every chess programmer has his little secrets - and specialities.
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.