When to clear the Transposition table?

[lithander]

I have added a simple transposition table to my engine. It seems to work well enough, I gained about 100 ELO from it, and even more in self-play.

But when exactly should I clear the transposition table?

I tested two main scenarios: where I clear the TT at the beginning of a each new search (whenever the engine receives a "go" command) and I also tested never clearing it unless "ucinewgame" is received.

Never clearing the TT sounds like the smart thing to do. In an ongoing game the current position was probably part of the searched tree two plies ago and is still in the TT. Another benefit of not clearing is that I don't have to reset 256MB of memory to the default values of the struct - maybe that matters in super fast timecontrols. (but there I wouldn't really need 256MB TT)

But on the other hand the search is now non-deterministic: If the previous search was on the same position ("go", "stop", "go") it now skips all the first iterations of the iterative deepening because the score is found in the TT. Then on the next depth it produces a PV that is not wrong (same score) but may be completely different than a search that starts from scratch.

I tested both variants and for me there wasn't a distinct advantage for either in my tests. Both performed the same in several thousand of games, more or less.

What do other engines usually do?

[MartinBryant]

I never clear it unless the GUI sends a 'clear hash' command.
But if you don't clear it you might want to ensure you have some 'aging' of entries to make sure it doesn't get clogged up with positions from previous searches that can never occur again.

[mvanthoor]

But on the other hand the search is now non-deterministic: If the previous search was on the same position ("go", "stop", "go") it now skips all the first iterations of the iterative deepening because the score is found in the TT.

Effectively you're always only searching the deepest depth.

So when you search 1, and then 1-2, you only actually search 2. Then when you search 1-2-3, you only search 3, and so on. The first few plies are very fast, but later plies cost lots more time to search. You only need to spend that time once, and then the engine can run through the depths and get to the next one almost instantly in the next iteration.

The problem is that in the superfast time controls we use for testing, you're often not going to reach the depths where this matters.

I tested both variants and for me there wasn't a distinct advantage for either in my tests. Both performed the same in several thousand of games, more or less.

You're not seeing any difference because of the superfast time controls. The main two perks of the TT in those time controls are in the endgame, especially if there are no sliders, and to provide the TT-move for sorting.

What do other engines usually do?

If you clear the TT on each new search, then why would you ever have a TT larger than 64 MB or something like that? Most engines don't clear the TT between searches. It would be bad if you use them for analysis. You've seen yourself what the effect of the TT is (go depth 10, go depth 10, go depth 10.... try it when clearing the TT and not clearing the TT, and see the time-to-depth).

[mvanthoor]

I never clear it unless the GUI sends a 'clear hash' command.
But if you don't clear it you might want to ensure you have some 'aging' of entries to make sure it doesn't get clogged up with positions from previous searches that can never occur again.

This often happens if a position with a huge depth is entered into the TT, and you have a replace-by-lowest-depth scheme (like I do). Then you'll lose an entry that can't be overwritten unless one comes in with an even larger depth.

[lucasart]

But when exactly should I clear the transposition table?

ucinewgame

[j.t.]

I am not clearing the hash table between moves of the same game, and it caused (and still sometimes causes) headaches. Debugging is really the worst. If you do this, I would really clear between different game (i.e. after "ucinewgame"). Then at least you can try to debug an issue by replaying the game by doing searches of the respective positions to the respective depths/nodecounts.

[pedrojdm2021]

Each new game i think?

in my engine i use only a 20mb tranposition table. (~875000 entries) that's because i do clear it at the begining of each search. I do not see any adventage of 100mb+ TT anyways

[hgm]

As long as you are developing, clear the TT before every search. Also the killer and history tables. To make sure your search is completely deterministic, and you can debug any problem that might surface in test games. You won't lose that much Elo because of it, and who cares whether you are testing versions against each other that are both a couple of Elo weaker than they could have been?

If you have a replacement scheme that protects larger depths, it is important you implement some mechanism that flushes these depths out of the table, or the entire TT (or the part where you do this) will in the end get poisoned by useless deep entries. Clearing the TT after every move allows you to ignore that problem (at least when the size of your search tree doesn't exceed the size of the TT by several orders of magnitude).

[lithander]

If you have a replacement scheme that protects larger depths, it is important you implement some mechanism that flushes these depths out of the table, or the entire TT (or the part where you do this) will in the end get poisoned by useless deep entries.

My TT is pretty simple. I compute the index = (zobristHash % TABLE_SIZE) and I just overwrite whatever is in there regardless of it's depth. I tried a few variants but this worked best. (I also don't have buckets)

The only case where I have and want persistent entries is to store repetitions which I enter explicitly before the search starts with a high constant depth (PERSISTENT_DEPTH = 9999) and a score of 0. Encountering an entry with this "special" depth means I don't overwrite it but return early.

Between searching different positions instead of clearing everything I just increase the PERSISTENT_DEPTH value (so not really a constant anymore) when I start a new search to un-freezing whatever history positions I previously had in there.

I am not clearing the hash table between moves of the same game, and it caused (and still sometimes causes) headaches.

How much ELO would you expect a typical engine would lose if you are clearing the TT between searches? In other words: what do you sacrifice for curing the headache once and for all? (And of course temporarily disabling it for debugging purposes is always possible but still...)

[j.t.]

How much ELO would you expect a typical engine would lose if you are clearing the TT between searches? In other words: what do you sacrifice for curing the headache once and for all? (And of course temporarily disabling it for debugging purposes is always possible but still...)

To be honest, at the time when I stopped clearing between moves, I didn't do individual tests for each feature I added. I'll do a test today or tomorrow how much Elo I am loosing when I enable clearing between moves.

The reason why I didn't stop using it was, that after each bug I fixed that was hard fixing because of clearing between moves, I thought that *now* my engine must be bug free (I mean, there can't be more bugs than code, right?!), so I didn't want to remove a feature that very likely adds Elo.