Which calculated data should be stored?

[smrf]

Using a cache storing two kind of evaluations and a probably best move, I am now unsure, whether this approach is optimal.

I am now thinking it over to only store there the probably best move, but no more evaluations - and to do this for all levels separately.

What is your opinion on this? May be there also are already made experiences concerning that question.

Reinhard.

[hgm]

Are you talking about the main hash table here, or the evaluation cache?

[smrf]

SMIRF is using only one cache for everything. Why should there be a split?

[Dann Corbit]

SMIRF is using only one cache for everything. Why should there be a split?

If (for instance) you have locked pawns, no need to constantly reevaluate them.
E.g.:
[d]8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - id "Fine.70";
The above position will perform drastically better if you have a pawn hash table (typically).

If you have an expensive eval, it makes sense to save it separately. Of course, you could store it in the regular hash as a zero ply search, but then how will you differentiate it from a qsearched 0 ply search? The answers will clearly be different. Perhaps you could store them as -1 plies or something.

[hgm]

SMIRF is using only one cache for everything. Why should there be a split?

Never mind why. It is what most programs do.

But I understand that you are talking about main hash table here, and that with 'evaluation' you mean the score (or score bound) returned by the search.

If you store no scores, you could never do a hash cutoff, and would always have to search the entire tree, even in nodes for positions where you have already been. You might search a minimal tree because you have the cut-moves available, but even the size of a minimal tree grows exponentially with depth. Because of that you would never reach 30 or 40 ply in positions like the one Dan gives above, and as a result, could never solve it. When storing scores, and using them in stead of re-searching, you solve it in a second or so.

Making separate tables is a bad idea: the same position might be present multiple times (for different searched depth), wasting memory space. In general, the largest searched depth would be the most accurate, and there is no need to store the others. If the search would only probe the table for its current depth it would use a less accurate result, while a more accurate one was available. Or it would not find a result, where even the move of a less accurate result would have been a helpful hint. And probing all tables to find the best result might be very expensive.

It is a good idea to balance the number of entries stored for each depth in the hash table, though.

[smrf]

SMIRF is using only one cache for everything. Why should there be a split?

Never mind why. It is what most programs do.

Maybe, but I am not basing SMIRF on other program sources. I am mostly more interested in good arguments instead of good examples or results.

I understand that you are talking about main hash table here, and that with 'evaluation' you mean the score (or score bound) returned by the search.

Well, for me the stored putative best move seems do be most important. Additionally I am storing a still basic detail evaluation of that position (I am thinking it over to also store a q-search value, but still refused to do this). Reusing of previously calculated bounds seems not to be that effective, may be, because I am not very effective in reusing results crossing different ply depth levels.

If you store no scores, you could never do a hash cutoff, and would always have to search the entire tree, even in nodes for positions where you have already been. You might search a minimal tree because you have the cut-moves available, but even the size of a minimal tree grows exponentially with depth. Because of that you would never reach 30 or 40 ply in positions like the one Dan gives above, and as a result, could never solve it. When storing scores, and using them in stead of re-searching, you solve it in a second or so.

In that example there is a split in calculating a detail evaluation by reusing shared pawn structure values. Of course this might be an additional step of a later optimization. But I noticed, that in his example there was very few interaction between non-K-P pieces and the pawns. In such a situation an evaluation split might be a legal orthogonal approach. But in more middle-game related positions I am still not convinced of the independence of both separated parts. Thus I am waiting for much more experiences before investigating the pros and cons of such a split.

Making separate tables is a bad idea: the same position might be present multiple times (for different searched depth), wasting memory space. In general, the largest searched depth would be the most accurate, and there is no need to store the others. If the search would only probe the table for its current depth it would use a less accurate result, while a more accurate one was available. Or it would not find a result, where even the move of a less accurate result would have been a helpful hint. And probing all tables to find the best result might be very expensive.

Because of such a kind of problems I give the stored best move a very high importance. Its reuse is 100% neutral to search depths, maybe its performance in contrast. But using bound values crossing search level differences is making me a lot of headaches. E.g. this destroys the ability to get a unique node evaluation, because it will depend on move sort or parallel tasks.

It is a good idea to balance the number of entries stored for each depth in the hash table, though.

Here I have a probably good replacement scheme. And I also have tested storing of node evaluations for different search levels, which does not seem to waste that much memory. But I skipped that approach because of a more consistent view of a single node - but still having that search level crossing problems I have mentioned.

Thank you all for answering to that problem field!