Stockfish change request.

[mcostalba]

Note that what you have as TT.store may be improved with a hypothetical TT.refresh depending on your internals. For instance, a simple store may end up with two copies of the same entry. A "refresh" may bump the last used entry up to make sure it is not a the bottom of the pile, without having two copies. Anyway, even if you end up with two copies of the same entry your new version may be better.

Two copies are not possible due to how TT works. But it is true that could speeded up a bit by a dedicated TT.refresh(TTEntry* ) that just updates the age value, called 'generation' in SF.

Anyhow this code is not so performance critical and the TT.store() is fast anyhow because all the values are already cached. So I prefer to stick to the simplest Joona's version instead of building up some new ad-hoc code.

If you are going to test this, it won't show a difference at fast games and big HT. Make sure that HT is somehow filled, reducing its size.

thanks for the hint.

[jwes]

When you get a value from the transition table that causes a cutoff, you can ensure that the generation of that entry is the current generation, either by always storing it, which is what crafty does, or by storing it only if the generation is different. This should give an improvement which is slight in fast games, significant in slow games, and large when doing back and forth analysis.

Sorry but I don't understand. TT entries are grouped in clusters. You are talking of overwrite an exsisting entry that corresponds to the _same_ position of the new one or to overwrite another position's entry ?

I am also not sure I understand, but I think he means that when a transposition table entry from a previous search (i.e. with a generation different from the current generation) proves useful in the current search, the generation of that entry should be replaced with the current generation, in order to prevent it from getting overwritten too easily. It sounds like an interesting idea to me. It probably won't make a big difference, but it is hard to see how it could hurt.

That is right. Adding a tt->refresh() function would be a little quicker, since you know which entry you want to change. The situation where this really helps is when you are doing deep analysis and you make a few moves until the program sees the point. When you unmake those moves to see other lines, it would be very good if those deeply analyzed positions that recur in the search were not overwritten.

[mcostalba]

When you get a value from the transition table that causes a cutoff, you can ensure that the generation of that entry is the current generation, either by always storing it, which is what crafty does, or by storing it only if the generation is different. This should give an improvement which is slight in fast games, significant in slow games, and large when doing back and forth analysis.

Sorry but I don't understand. TT entries are grouped in clusters. You are talking of overwrite an exsisting entry that corresponds to the _same_ position of the new one or to overwrite another position's entry ?

I am also not sure I understand, but I think he means that when a transposition table entry from a previous search (i.e. with a generation different from the current generation) proves useful in the current search, the generation of that entry should be replaced with the current generation, in order to prevent it from getting overwritten too easily. It sounds like an interesting idea to me. It probably won't make a big difference, but it is hard to see how it could hurt.

That is right. Adding a tt->refresh() function would be a little quicker, since you know which entry you want to change. The situation where this really helps is when you are doing deep analysis and you make a few moves until the program sees the point. When you unmake those moves to see other lines, it would be very good if those deeply analyzed positions that recur in the search were not overwritten.

Thanks for the explanation. Actually I missed that Tord was right, sorry for this. If the test proves succesful I will profile SF and check if we have a performance penalty for the TT.store() call or, as I guess, the impact is harmless. In the latter case a TT.refresh(tte) that calls a tte->refresh(generation), because 'generation' parameter is kept in TT, just adds code for nothing.

[Arpad Rusz]

I am using engines mostly for analysing endgames. Stockfish seems a very strong engine but it doesn't use tablebases... Do you plan to add that feature?

[Dann Corbit]

I am using engines mostly for analysing endgames. Stockfish seems a very strong engine but it doesn't use tablebases... Do you plan to add that feature?

It's open source, so anyone can add it who wants to do that.
Miguel's tablebase format has a license that is amenable to any sort of use.

[jwes]

Are you talking about sth like this?

I have started a test with the following patch:

Code: Select all

Date: Thu, 29 Apr 2010 18:21:48 +0100
Subject: [PATCH] Refresh TT entry after a cut-off to avoid aging

Re-save the same TT entry if value is usable and allow
us to cut-off, it means that entry is valuable and
we want to keep it fresh updating the 'generation'
parameter up to the current value.

Patch suggested by J. Wesley Cleveland and better
clarified by Miguel A. Ballicora.

---
 src/search.cpp |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/search.cpp b/src/search.cpp
index b2b2414..84f5273 100644
--- a/src/search.cpp
+++ b/src/search.cpp
@@ -1301,6 +1301,9 @@ namespace {
 
     if (tte && ok_to_use_TT(tte, depth, beta, ply))
     {
+        // Refresh tte entry to avoid aging
+        TT.store(posKey, tte->value(), tte->type(), tte->depth(), tte->move());
+
         ss[ply].currentMove = ttMove; // Can be MOVE_NONE
         return value_from_tt(tte->value(), ply);
     }
@@ -1624,6 +1627,9 @@ namespace {
     {
         assert(tte->type() != VALUE_TYPE_EVAL);
 
+        // Refresh tte entry to avoid aging
+        TT.store(pos.get_key(), tte->value(), tte->type(), tte->depth(), tte->move());
+
         ss[ply].currentMove = ttMove; // Can be MOVE_NONE
         return value_from_tt(tte->value(), ply);
     }
-- 
1.6.5.1.1367.gcd48

It probably is not necessary to to this in the qsearch as it is very unlikely that a qsearch will have such a large depth that the cost of a re-search is high.

[mcostalba]

It probably is not necessary to to this in the qsearch as it is very unlikely that a qsearch will have such a large depth that the cost of a re-search is high.

Ok, test is finished. I have run a match with 64MB hash size that is a little bit smaller then usual but not too small because I would avoid artifacts due to unrealistic hash sizes. Test result is slightly positive, but just very slightly.

I have now started another test with your above proposal: remove the TT entry refresh from qsearch....