Author: Tony Werten
Date: 12:47:50 04/06/01
Go up one level in this thread
On April 05, 2001 at 06:54:30, David Rasmussen wrote: >I know that most people (including me) do not store results in the hashtable >during Qsearch, because there are too many positions to keep, and valuable >positions closer to the root would get overwritten etc. It's doesn't have to be that bad if you have a 2 level hashtable. First level is only replace when new depth is higher, second always replace. I store first 3 plies of quiescence in my normal hashtable wich gave the best result. Mind you, I do checks in qsearch so having a hastablehit might give me more than somebody who doesn't. It also depends on your search speed. If you search 1M nodes/sec, probably half of them are in qsearch. If half of them are in the first 3 ply you'll fill up 250K positions/sec. I'm using 16 byte/entry so that fills 4 MB/s. It's hard to keep buying your RAM at that speed ( I always knew it was cheaper to be a slow searcher ) So basicly it depends on your program. Try it and you'll know it. For me it works ( checks in qsearch, slow eval ) and I'm quite sure for fe Crafty ( no checks, skip loosing captures ) it doesn't. Tony > >But have anybody tried a seperate Qsearch hashtable? The very fact that the >Qsearch generates so many notes, and so much time is spent there, seems to >dictate that the dynamic programming principle of a trans/ref table would be >very beneficial here too.
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.