qsearch hashing

[AndrewShort]

do you hash in qsearch?

I don't, but I'm wondering if I should. A lot of nodes are qnodes, so it seems logical hashing would help.

In the main search, saving a hash means saving the depth searched, and reading the hash means comparing depth-to-search to the depth searched.

In qsearch, that logic does not apply, since qsearch by definition simply exhausts depth until a cutoff or a quiescent position.

So I'm thinking of re-using my existing hash code, like this:

(1) qsearch savehash would save with "0" depth searched.

(2) qsearch readhash would pass 0 as the depth-to-search. This way, qsearch can sucessfully read any same position saved from the main hash or qsearch hash. One issue here is the hash bestmove might be a non-capture / non-promotion, which qsearch cannot consider - so bestmove would be used only if capture or promotion.

(3) since qsearch would save with 0 depth (see (1) above), the main search would never use a qsearch pos in the hash for the score, and you wouldn't want to, since not all moves were considered. The main search would not want to use that bestmove, either. Perhaps qsearch savehash should never save a bestmove.

Does that sound right?

[xsadar]

do you hash in qsearch?

I don't, but I'm wondering if I should. A lot of nodes are qnodes, so it seems logical hashing would help.

In the main search, saving a hash means saving the depth searched, and reading the hash means comparing depth-to-search to the depth searched.

In qsearch, that logic does not apply, since qsearch by definition simply exhausts depth until a cutoff or a quiescent position.

So I'm thinking of re-using my existing hash code, like this:

(1) qsearch savehash would save with "0" depth searched.

(2) qsearch readhash would pass 0 as the depth-to-search. This way, qsearch can sucessfully read any same position saved from the main hash or qsearch hash. One issue here is the hash bestmove might be a non-capture / non-promotion, which qsearch cannot consider - so bestmove would be used only if capture or promotion.

(3) since qsearch would save with 0 depth (see (1) above), the main search would never use a qsearch pos in the hash for the score, and you wouldn't want to, since not all moves were considered. The main search would not want to use that bestmove, either. Perhaps qsearch savehash should never save a bestmove.

Does that sound right?

I don't see why you wouldn't want to use a qsearch bestmove in a normal search. True, it didn't consider non-captures, but without a hash move, you're just going to search captures first anyway, and what better capture to search first than the one qsearch thought was the best? It might not save you much, but if you have it, you might as well use it, I think.

[Zach Wegner]

do you hash in qsearch?

Yes.

I don't, but I'm wondering if I should. A lot of nodes are qnodes, so it seems logical hashing would help.

In the main search, saving a hash means saving the depth searched, and reading the hash means comparing depth-to-search to the depth searched.

In qsearch, that logic does not apply, since qsearch by definition simply exhausts depth until a cutoff or a quiescent position.

So I'm thinking of re-using my existing hash code, like this:

(1) qsearch savehash would save with "0" depth searched.

That doesn't work for me. Depth in qsearch does matter, since I use checks in qsearch depending on the depth.

(2) qsearch readhash would pass 0 as the depth-to-search. This way, qsearch can sucessfully read any same position saved from the main hash or qsearch hash. One issue here is the hash bestmove might be a non-capture / non-promotion, which qsearch cannot consider - so bestmove would be used only if capture or promotion.

(3) since qsearch would save with 0 depth (see (1) above), the main search would never use a qsearch pos in the hash for the score, and you wouldn't want to, since not all moves were considered. The main search would not want to use that bestmove, either. Perhaps qsearch savehash should never save a bestmove.

Does that sound right?

There's no reason not to store a best move. All it does is help move ordering.

I also use a separate qsearch hash that's pretty small (a meg or two) so it can stay mostly in cache. This is because an access to main memory (non-cached) is very expensive, a few hundred cycles or so (?). Because qsearch nodes are around 70-80% of all nodes (for me at least), speed becomes a bit more important than search tree reductions, because the trees are pretty small anyways. I do use the same hash table structure though, so that I can use the same probe and store code.

[BubbaTough]

I do not hash Qsearch, Eval, or Pawn stuff. I have tried Qsearch and Eval hashes a couple times, with no luck...my guess is all three are helpful if done well but not if done poorly.

-Sam

[AndrewShort]

do you hash in qsearch?

I don't, but I'm wondering if I should. A lot of nodes are qnodes, so it seems logical hashing would help.

In the main search, saving a hash means saving the depth searched, and reading the hash means comparing depth-to-search to the depth searched.

In qsearch, that logic does not apply, since qsearch by definition simply exhausts depth until a cutoff or a quiescent position.

So I'm thinking of re-using my existing hash code, like this:

(1) qsearch savehash would save with "0" depth searched.

(2) qsearch readhash would pass 0 as the depth-to-search. This way, qsearch can sucessfully read any same position saved from the main hash or qsearch hash. One issue here is the hash bestmove might be a non-capture / non-promotion, which qsearch cannot consider - so bestmove would be used only if capture or promotion.

(3) since qsearch would save with 0 depth (see (1) above), the main search would never use a qsearch pos in the hash for the score, and you wouldn't want to, since not all moves were considered. The main search would not want to use that bestmove, either. Perhaps qsearch savehash should never save a bestmove.

Does that sound right?

I don't see why you wouldn't want to use a qsearch bestmove in a normal search. True, it didn't consider non-captures, but without a hash move, you're just going to search captures first anyway, and what better capture to search first than the one qsearch thought was the best? It might not save you much, but if you have it, you might as well use it, I think.

that's a good point!

[mcostalba]

I do not hash Qsearch, Eval, or Pawn stuff. I have tried Qsearch and Eval hashes a couple times, with no luck...my guess is all three are helpful if done well but not if done poorly.

-Sam

I have experimented with Glaurung 2.1.

I have found a very good improvment when hashing in qsearch.

My guess is that in Glaurung 2.1 evaluation() is quite expensive (42% of time is spent there), so hashing the qsearch is good because it allows to avoid calling _again_ the costly evaluation when the position is found.

We have also to say that in Glaurung 2.1 evaluation is called in each qsearch node to calculate a "stand pat score", not only on leaf nodes.


Marco