Author: Stuart Cracraft
Date: 21:25:04 07/28/04
Go up one level in this thread
>Before starting the main loop (that does a search of the children) ETC will >check the positions reached by each of the children to check the hash signatures >and whether a cutoff can be done. With perfect moveordering this will not get >you anything. But when not the first but e.g. the third move will get you a beta >-cutoff, ETC will enable you to do a cutoff fast, without searching the first >two moves. In MTD, the chances that children's positions are already in the >hashtable is bigger than in regular PVS, so the gain may be bigger there. > >But watchout for the pitfalls. Also consider extensions that you may do on >certain moves to determine whether an entry found in the hashtable has >sufficient depth. > >What I'm doing to make sure that the cutoff is ok, is that I do not do an >immediate cutoff. Instead I replace the hashmove by the move that should create >a cutoff according to ETC. >This got me a few percent speedup although I'm using PVS. >Oh, one thing more: As ETC costs a bit, only do it when the remaining depth is >high enough to make up for the costs. I'm only doing ETC based moveordering when >there are at least 4 ply to go. Tried ETC with MTD(f) with 30 position test @ 1 second each for any depth in main search (and some quiescence). Total tree reduction was 25%. Same for PVS/NEGASCOUT with MTD(f). 25%. Overhead of ETC was high though and the time savings was very small (1%) for ETC-enhanced versions. Anyway... research results reproduced but practical benefit minor for small, fast searches (expected). Need more testing. Probably will prove helpful for longer searches typical in a normal game. Stuart
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.