Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: What makes Junior so good?

Author: Peter McKenzie

Date: 17:09:06 05/01/00

Go up one level in this thread


On May 01, 2000 at 18:50:24, Robert Hyatt wrote:

>On April 30, 2000 at 22:34:17, Christophe Theron wrote:
>
>>On April 30, 2000 at 18:42:57, Amir Ban wrote:
>>
>>>On April 30, 2000 at 16:39:04, Christophe Theron wrote:
>>>
>>>>On April 30, 2000 at 06:47:29, Amir Ban wrote:
>>>>
>>>>>On April 29, 2000 at 11:31:09, Eran wrote:
>>>>>
>>>>>>
>>>>>>I am sorry if I said it. Okay I believe you that Junior6 has underpromotion code
>>>>>>and that's wonderful. Maybe I will consider buying it. Does Junior6 consume
>>>>>>hashtable memory as large as fritz does? Is having large hashtable memory
>>>>>>important for Junior6? Is 40 MB hashtable enough for 40/120 games?
>>>>>>
>>>>>>Eran
>>>>>
>>>>>More memory for hash is good, but Junior is not very sensitive to it and you can
>>>>>change memory size by order of magnitude without obvious effect on playing
>>>>>strength.
>>>>>
>>>>>The comparison to Fritz is interesting and backward: I believe that Fritz 6
>>>>>(new) consumes less memory than previous versions and the reason may be a
>>>>>conversation I had with Frans about this in Paderborn, from which he may have
>>>>>decided that he doesn't need so much memory.
>>>>>
>>>>>Amir
>>>>
>>>>
>>>>
>>>>I must admit I don't understand what you say...
>>>>
>>>>
>>>>    Christophe
>>>
>>>
>>>Then why don't you ask :)
>>>
>>>I understood from Frans that he's hashing quiescence nodes. I told him I don't,
>>>and that I consider it a waste of time.
>>>
>>>Amir
>>
>>
>>
>>I hash quies nodes. I tried both methods (hashing them and not hashing them) and
>>found that hashing QSearch nodes was definitely better, but not by much. I did
>>hours of experiments and drew a lot of curves with my spreadsheet in order to
>>find this.
>>
>>It works better even if the hash table is highly saturated.
>>
>>That's how it works for me. I don't think that I have a better hashing/replacing
>>strategy, actually it is rather simplistic. Maybe it's because I do more in
>>QSearch than both of you do, although I cannot know for sure.
>>
>>Maybe I should check again... :)
>>
>>
>>
>>    Christophe
>
>
>I used to hash q-search nodes.  I found it reduced the size of the tree by about
>10%.  I also found that by taking it out, I reduced the total search time by
>15 %.  A net gain of 5%.  More importantly, I don't need nearly the hash memory
>now since over half of the search is not hashed.

I can't remember for certain, but I think I do hash the q-search.  Like
Christophe/Tiger (but unlike Crafty), I do a bit more that just the minimal
q-search, so perhaps this is what makes hashing those nodes worthwhile for our
programs.

>
>My next task is to save some time by getting rid of the hashing/unhashing code
>in the q-search as well, since it isn't used...

I assume you are talking about updating the hash key?  Surely this is a tiny
overhead, but it all adds up I guess.  I wonder if the speedup (if any) will
offset the added complexity in your make/unmake functions, or do you plan to
create new versions of make/unmake?

Sounds like you don't probe the hash table in q-search either?  I think I do,
but don't have my source code handy to check.


cheers,
Peter



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.