Author: Christophe Theron
Date: 00:54:09 05/02/00
Go up one level in this thread
On May 02, 2000 at 02:52:33, Tony Werten wrote:
>On May 01, 2000 at 20:39:13, Christophe Theron wrote:
>
>>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%.
>>
>>
>>
>>Yes, that's approximately what I measured.
>>
>>
>>
>>
>>> I also found that by taking it out, I reduced the total search time by
>>>15 %. A net gain of 5%.
>>
>>
>>
>>That's where I differ. Taking hash probe/updating out of QSearch results in a
>>very marginal speed gain (in NPS) for me.
>>
>>
>>
>>
>>> More importantly, I don't need nearly the hash memory
>>>now since over half of the search is not hashed.
>>
>>
>>
>>I think there is no saving in memory. In QSearch, if the hash table slot is
>>available, I use it and will maybe gain something, and if it's not available
>>(because a more important information is stored) I end up not using the hash
>>info in QSearch, as you do.
>>
>>Not hashing in QSearch means you are not taking advantage of all the memory you
>>have to help you to decrease the size of your tree. It does not mean that you
>>will need less memory.
>>
>>You do not take advantage of a resource you have, as your result of a 10%
>>smaller tree when using HT in QSearch shows.
>>
>>Of course, the increased NPS in your case justifies your choice.
>>
>>
>>
>>
>>>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...
>>
>>
>>Yes, I thought of this possible speed gain. But then you have to write a special
>>version of make/unmake that you will use exclusively in QSearch, and design
>>another system to check for repetitions for example (as I assume that you use
>>the hash key to detect repetitions).
>
>How many quit moves do you allow in QSearch ? Do you allow all checkgiving moves
>as well ( even if they are not captures )? Allowing all checkgiving moves, then
>all checkevasive moves... isn't that the fastest way to blowup your QSearch ?
>
>>
>>This is maybe worth the effort for you, because you just generate captures in
>>QSearch (that means no repetition can happen in QSearch). But my QSearch does
>>more than that, so for me it's a real problem. My QSearch catches a lot of draws
>>by repetition.
>
>I guess that's where the difference is. Since you trie a lot more moves in
>Qsearch, it would be logical you have more to gain from hashing.
>
>There is a middleway. Just store say the first 4 plies in QSearch and always
>trie to retrieve. For my program this seems to work the most efficient. (If I
>could just get the rest of the program efficient)
>
>Didn't think about using a different make_move after those 4 plies, should give
>a speedup.
>
>Tony
A marginal speedup. Almost all the time is consumed in the last plies of the
normal search and in the first ply of QSearch. Deeper plies do not count much.
They are important in term of quality of play, but do not impact much of the
speed performance.
It is simpler to adopt a consistent strategy for the whole QSearch: use HT or
not. It is also more friendly to the L1 cache.
Christophe
>>You also need to keep the hashing of pawn structures anyway, so all hashing will
>>not be taken out of the QSearch make/unmake.
>>
>>
>>But I understand that not hashing in QSearch can be a good decision for some
>>programs.
>>
>>
>>
>> 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.