hashing in quiescent

[adams161]

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

[mjlef]

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.

[bob]

............ there are many more quiescence nodes than non q-nodes in a typical search. ...............
--Jon

Now I am worried. Mine hovers around the 10% of level.

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%)

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.

[jdart]

> 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

[adams161]

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

[Jan Brouwer]

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

Hi Jon,

Can you give some statistics about the effectiveness of the eval cache, such as number of entries and hit rate?

Thanks,

Jan

[rvida]

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

Hi Jon,

Can you give some statistics about the effectiveness of the eval cache, such as number of entries and hit rate?

Thanks,

Jan

A sample output from Critter after 14 ply search in position WAC.196:

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

[Jan Brouwer]

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

Hi Jon,

Can you give some statistics about the effectiveness of the eval cache, such as number of entries and hit rate?

Thanks,

Jan

A sample output from Critter after 14 ply search in position WAC.196:

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

Thanks.

So it could give a modest speed improvement, I'll have to try it sometime.