How often do engines clear their hash memory

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Onegin
Posts: 11
Joined: Sat Mar 12, 2016 12:40 am

How often do engines clear their hash memory

Post by Onegin » Wed Apr 12, 2017 10:48 pm

I've noticed that some engines (like Komodo 10 and Komodo 9) do NOT clear their hash memory between moves and accumulate hash until it gets to 99.999% or 100%, whereas others (like Stockfish 8 and Stockfish 7) clear their memory between moves. What is the reasoning for this behavior?

Dann Corbit
Posts: 11111
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: How often do engines clear their hash memory

Post by Dann Corbit » Wed Apr 12, 2017 11:23 pm

Onegin wrote:I've noticed that some engines (like Komodo 10 and Komodo 9) do NOT clear their hash memory between moves and accumulate hash until it gets to 99.999% or 100%, whereas others (like Stockfish 8 and Stockfish 7) clear their memory between moves. What is the reasoning for this behavior?
I guess that Komodo has a better replacement scheme.

In general, if I am analyzing a game or a pile of EPD records that are related to one another, I do not want the engine to clear hash between moves.

But if it finds a position that is not found in the hash, then it would be sensible to clear it.

I will get double the depth of analysis if I analyze closely related positions without clearing the hash. But if the positions are not related and I do not clear the hash, then the analysis will be hampered because the hash table is full of the wrong stuff.

It is even more important if I am backsolving, by analyzing the game backwards.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

mjlef
Posts: 1451
Joined: Thu Mar 30, 2006 12:08 pm
Contact:

Re: How often do engines clear their hash memory

Post by mjlef » Thu Apr 13, 2017 2:02 am

Onegin wrote:I've noticed that some engines (like Komodo 10 and Komodo 9) do NOT clear their hash memory between moves and accumulate hash until it gets to 99.999% or 100%, whereas others (like Stockfish 8 and Stockfish 7) clear their memory between moves. What is the reasoning for this behavior?
All programs I have seen just keep replacing hash entries. Komodo only clears the hash used counter when Clear Hash is selected. Other programs reset it with each new search. The UCI spec does not say what is correct, but since I have grown tired of explaining this I am likely to change this in a future version. Don programmed it this way and I have just left it. It is really only useful in helping select the Hash size when you choose a different time control or number of Threads.

Hash tables are never really "full". They just replace existing entries (aging the table). Programs would play much worse if they cleared the Hash table between moves. But it is best to be able to hold most of a given search in memory, to prevent researching (and for move ordering).

Onegin
Posts: 11
Joined: Sat Mar 12, 2016 12:40 am

Re: How often do engines clear their hash memory

Post by Onegin » Thu Apr 13, 2017 6:43 pm

Thanks for your explanation. I guess it comes with "fame and fortune", the necessity to answer same questions over and over again... If you still have a second...
It looks from my inexperienced point of view that keeping hash is a better/more efficient approach. But then why do latest versions of Stockfish (7 and 8) clear hash between moves?

Dann Corbit
Posts: 11111
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: How often do engines clear their hash memory

Post by Dann Corbit » Thu Apr 13, 2017 6:51 pm

mjlef wrote:
Onegin wrote:I've noticed that some engines (like Komodo 10 and Komodo 9) do NOT clear their hash memory between moves and accumulate hash until it gets to 99.999% or 100%, whereas others (like Stockfish 8 and Stockfish 7) clear their memory between moves. What is the reasoning for this behavior?
All programs I have seen just keep replacing hash entries. Komodo only clears the hash used counter when Clear Hash is selected. Other programs reset it with each new search. The UCI spec does not say what is correct, but since I have grown tired of explaining this I am likely to change this in a future version. Don programmed it this way and I have just left it. It is really only useful in helping select the Hash size when you choose a different time control or number of Threads.

Hash tables are never really "full". They just replace existing entries (aging the table). Programs would play much worse if they cleared the Hash table between moves. But it is best to be able to hold most of a given search in memory, to prevent researching (and for move ordering).
Pretty please, down on my knees, don't simply remove it.
If you make it a UCI option with false as the default that is fine.

It literally gives one free ply when analyzing consecutive positions from a game or from an opening being studied.

It is like getting twice as much time for free.

It was me who asked Don for this.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Dann Corbit
Posts: 11111
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: How often do engines clear their hash memory

Post by Dann Corbit » Thu Apr 13, 2017 6:52 pm

Onegin wrote:Thanks for your explanation. I guess it comes with "fame and fortune", the necessity to answer same questions over and over again... If you still have a second...
It looks from my inexperienced point of view that keeping hash is a better/more efficient approach. But then why do latest versions of Stockfish (7 and 8) clear hash between moves?
It was Forest Gump who said, "Stupid is as stupid does."
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Dann Corbit
Posts: 11111
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: How often do engines clear their hash memory

Post by Dann Corbit » Thu Apr 13, 2017 6:54 pm

Dann Corbit wrote:
Onegin wrote:Thanks for your explanation. I guess it comes with "fame and fortune", the necessity to answer same questions over and over again... If you still have a second...
It looks from my inexperienced point of view that keeping hash is a better/more efficient approach. But then why do latest versions of Stockfish (7 and 8) clear hash between moves?
It was Forest Gump who said, "Stupid is as stupid does."
It does make sense under the following scenario:
1. You have a substandard replacement scheme
2. You are analyzing a group of unrelated positions.

Clearing the hash will make the analysis better in that case [processing a list of unrelated positions].
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: How often do engines clear their hash memory

Post by Evert » Thu Apr 13, 2017 7:18 pm

Dann Corbit wrote:But if the positions are not related and I do not clear the hash, then the analysis will be hampered because the hash table is full of the wrong stuff.
This seems surprising: most engines will always store something at the end of the search, in which case it should not matter if there is unrelated junk in the hash table, since it will be replaced by something useful anyway.

Dann Corbit
Posts: 11111
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: How often do engines clear their hash memory

Post by Dann Corbit » Thu Apr 13, 2017 7:54 pm

Evert wrote:
Dann Corbit wrote:But if the positions are not related and I do not clear the hash, then the analysis will be hampered because the hash table is full of the wrong stuff.
This seems surprising: most engines will always store something at the end of the search, in which case it should not matter if there is unrelated junk in the hash table, since it will be replaced by something useful anyway.
It only matters if you do not have a really good replacement strategy.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
hgm
Posts: 24534
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: How often do engines clear their hash memory

Post by hgm » Thu Apr 13, 2017 8:23 pm

Unused hash is useless hash...

The only reason I can see for clearing the table before every move is reproducibility of bugs; on a fully debugged engine there is no need to do that. Even clearing before a new game isn't really useful. (Unless you changed variant...)

I have had a lot of trouble finding a replecement scheme that works satisfactorily with back-solving. Especially in the case where the main line forks to two branches, both to deep to recognize their value from the forking point. Then I have to back-solve from one branch end-point to the fork, and then from the other, to get them both correct in the fork (in particular, both bad). Very often the back solving of one branch uses so much hash that the score of the other branch has been overwritten, and vice versa.

In particular schemes that use aging by search number make the engine practically useless, when they count every move or undo during the analysis session as a new search. Because that would immediately declare the positions of branch A fair game for replacement when you enter branch B.

OTOH, if you consider the entire analysis session one search, the depth-preferred part of the table fills up completely with the deepest entries of all searches combined, leaving no room for the current search in a long session. The search becomes very sluggish then. So my currently favored replacement scheme uses a small part of the table for depth-preferred + aging, (where during a analysis session aging is suppressed), and uses the rest of the table with equidistributed draft, (where even un-aged deep entries can be replaced by shallower ones when their draft occupies more than its fair share of the table).

Post Reply