Author: Robert Hyatt
Date: 06:25:33 05/21/98
Go up one level in this thread
On May 21, 1998 at 09:14:21, Ernst A. Heinz wrote: >On May 21, 1998 at 08:29:51, Robert Hyatt wrote: > >>I see two problems to solve. First you can get a hash hit, but no >>suggested >>move... > >Just don't store entries without a suggested best move in the table. you do realize that 1/2 of the positions fit this category? IE *every* fail low node (where you store the flag "UPPER_BOUND" has no "best" move associated with it, since *every* move was bad.... So I'm not sure I follow what you mean here... > >>because this is a PV node and you have no PV (hash) move to follow, you >>have >>to take some evasive action to avoid calling LookUp() in the iterative- >>deepening call to Search()... or else you have to defer storing the >>"open" >>hash entry until you pass the IID part... >>I tried it both ways... and didn't like the complexity... > >Right, we simply defer flagging the entries in the table until after >the internal iterative deepening part. I don't think this is more >complex than handling an extra move stack for repetition detection >but there is surely room for disagreement here ... that was the way I tried it. I originally wanted to use "LookUp()" to set the open entry as well, as it must be called anyway. But I do that before IID... The trick to the repetition list is to use the 50 move rule counter "backward"... this tells you how far back in the list you have to search before being "sure" there is no repetition, because there is no need to search backward beyond a capture, pawn push, something that changes the castling status, etc... And since we search so many captures and pawn pushes, the average length for searching is 3-4 entries max... except for bizarre locked up pawn positions where the hash table is going to be hit more often than the repetition check anyway... > >>I tried it both ways... and didn't like the complexity... Ken Thompson >>used this however, but didn't do IID at all. My experiments offered no >>speed improvement over the repetition_list approach (this can be fast if >>you implement 50-move draws because you don't have to check the entire >>repetition list and it stays very short as well). > >For "Crafty" this may be true -- for other programs like "DarkThought" >the "open hashing" approach is definitely faster. It probably depends >on the general memory requirements of the programm -- the more memory >you use in other parts of the program the less it will suffer from an >additional repetition list. > >=Ernst= My memory requirements seem modest, based on tests on my quad-alr... which doesn't slow down at all whether I run 1 crafty or 4 identical copies doing the same search, while other programs can take a 20% hit quite easily when I run two of them at once...
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.