sounds like you might be fine then, but to point out the relavence of his comment in relation to qnodes and hashing and percentage of search nodes, you hash every time a qnode is called, in fact from my counters teh greatest number of hash hits are comming at depth 0 or the first call, which taking bobs suggestion of hashing before evaluating, saves me some evaluate work, but because qnodes are such a large number, at least 60% of all search nodes typically, there can be a complaint if you are not careful, that you are filling up your hash table with end nodes and possibly eraseing earier nodes that would do more work for you if they were allowed to create cuttofs.
Outside of hashing i dont know of any qnode counting method that is better or worse except as you have realized, to be able to speak comparitively with others
Mike
hashing in quiescent
Moderators: hgm, Rebel, chrisw
-
- Posts: 626
- Joined: Sun May 13, 2007 9:55 pm
- Location: Bay Area, CA USA
- Full name: Mike Adams
-
- Posts: 1494
- Joined: Thu Mar 30, 2006 2:08 pm
Re: hashing in quiescent
That sounds a bit dangerous. What about capturing one side's last pawn? That could easily change a score from losing to a drawish ending. I think a lot of people miss these things in qsearch. Something like a "losing" BxP could really change the score a lot.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: hashing in quiescent
You must not be counting them correctly. Most likely you are counting the first level q-search nodes as normal nodes. Otherwise for every frontier node, you must call qsearch which produces a q-search node.frankp wrote:Now I am worried. Mine hovers around the 10% of level.jdart wrote:............ there are many more quiescence nodes than non q-nodes in a typical search. ...............
--Jon
time 8.05 sec 3.26M nps (26.28M nodes)
ABnodes 23.21M (88.31%) qNodes 3.07M (11.69%)
time 7.96 sec 3.29M nps (26.15M nodes)
ABnodes 23.33M (89.23%) qNodes 2.82M (10.77%)
-
- Posts: 4368
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: hashing in quiescent
> You should store the final result as you exit this ply, and you should probe before you do _any_ work when you reach this ply.
This is basically what I do, but I store less info than I do for a regular hash entry and I limit the size of the table used for q-nodes.
--Jon
This is basically what I do, but I store less info than I do for a regular hash entry and I limit the size of the table used for q-nodes.
--Jon
-
- Posts: 626
- Joined: Sun May 13, 2007 9:55 pm
- Location: Bay Area, CA USA
- Full name: Mike Adams
Re: hashing in quiescent
well pulsar is not sophisticated enough to keep track of draws right now so its not an issue. But there is no reason to think it wouldnt play the move. i would give it the current evaluate score, plus the full value of the pawn with no recapture in the test i outlined. If that wasnt enough to improve alpha, particularly when alpha is deprecated to alpha -50, it must feel it can win more material in other lines.
The problem i have when i'm generous in what i search in qsearch, is it really slows the program down. It may pay off on select moves but i figure overall it kills me. If i just do all captures then qsearch nodes go up to 80% of search and i might get almost one less depth on average. Special cases arent worth giving up a depth.
I figure qsearch is the search of last resort. I rely on it to correct errors in search, i.e. a false sense that it can stand pat after search and call it a day. but overall i want my search to happen in search not qsearch, as qsearch, not playing 80% or more of the moves, is not going to be a subsitute for regular search.
Mike
The problem i have when i'm generous in what i search in qsearch, is it really slows the program down. It may pay off on select moves but i figure overall it kills me. If i just do all captures then qsearch nodes go up to 80% of search and i might get almost one less depth on average. Special cases arent worth giving up a depth.
I figure qsearch is the search of last resort. I rely on it to correct errors in search, i.e. a false sense that it can stand pat after search and call it a day. but overall i want my search to happen in search not qsearch, as qsearch, not playing 80% or more of the moves, is not going to be a subsitute for regular search.
Mike
-
- Posts: 201
- Joined: Thu Mar 22, 2007 7:12 pm
- Location: Netherlands
Re: hashing in quiescent
Hi Jon,jdart wrote: That said, I have for many years kept a small eval cache that holds recent full evaluations (it doesn't hold evals that are cut off early by futility checking in the eval code). The call to evaluate() checks the cache and returns the cached value if it is there. Depth doesn't matter for this: either the value exists in the cache or it doesn't and if does it is valid.
--Jon
Can you give some statistics about the effectiveness of the eval cache, such as number of entries and hit rate?
Thanks,
Jan
-
- Posts: 481
- Joined: Thu Apr 16, 2009 12:00 pm
- Location: Slovakia, EU
Re: hashing in quiescent
A sample output from Critter after 14 ply search in position WAC.196:Jan Brouwer wrote:Hi Jon,jdart wrote: That said, I have for many years kept a small eval cache that holds recent full evaluations (it doesn't hold evals that are cut off early by futility checking in the eval code). The call to evaluate() checks the cache and returns the cached value if it is there. Depth doesn't matter for this: either the value exists in the cache or it doesn't and if does it is valid.
--Jon
Can you give some statistics about the effectiveness of the eval cache, such as number of entries and hit rate?
Thanks,
Jan
Code: Select all
time: 7547 nodes: 3631122 qnodes: 2644684 fh: 94.38%
extchk: 203756 ext1rep: 4512 extpawn: 4095 evals: 0
tt.hit: 41.20% tt.exact: 0.06% tt.alpha: 8.54% tt.beta: 20.13%
phash: 95.31% evalcache: 15.04%
This is with 64 Mb main hash, 65536 entries of eval cache, 32768 entries pawn hash
-
- Posts: 201
- Joined: Thu Mar 22, 2007 7:12 pm
- Location: Netherlands
Re: hashing in quiescent
Thanks.rvida wrote:A sample output from Critter after 14 ply search in position WAC.196:Jan Brouwer wrote:Hi Jon,jdart wrote: That said, I have for many years kept a small eval cache that holds recent full evaluations (it doesn't hold evals that are cut off early by futility checking in the eval code). The call to evaluate() checks the cache and returns the cached value if it is there. Depth doesn't matter for this: either the value exists in the cache or it doesn't and if does it is valid.
--Jon
Can you give some statistics about the effectiveness of the eval cache, such as number of entries and hit rate?
Thanks,
JanCode: Select all
time: 7547 nodes: 3631122 qnodes: 2644684 fh: 94.38% extchk: 203756 ext1rep: 4512 extpawn: 4095 evals: 0 tt.hit: 41.20% tt.exact: 0.06% tt.alpha: 8.54% tt.beta: 20.13% phash: 95.31% evalcache: 15.04%
This is with 64 Mb main hash, 65536 entries of eval cache, 32768 entries pawn hash
So it could give a modest speed improvement, I'll have to try it sometime.