Komodo 9 and hash table usage

[zullil]

Both SCID-vs-PC and Arena 3.5 show (incorrectly?) that Komodo 9 does not clear hash between moves. The % of hash used continues to grow with each move in a game. Is that what is actually happening or are the two GUIs just not able to accurately report Komodo 9 hash table usage?

The Komodo 9 behavior (if hash is not cleared between moves) is different from Stockfish and every other engine I can think of at the moment. Does this give Komodo 9 an advantage in the programmer's eyes?

The "philosophy" of the UCI protocol is focused on positions. The engine is sent a position and directed to search. During the search, the engine is supposed to send info---info about the search in progress. Stuff like pv, score, nps, etc. Hashfull is included in this info, so the implication is that the number sent represents (an approximation to) the fraction of the hash table filled with entries related to the current search. But the protocol seems imprecise about this---see below. If Komodo is reporting a non-zero hashfull value at the start of a new search, then it seems to be interpreting the protocol differently than intended. At least, that's my (inexpert) opinion.

* info
the engine wants to send infos to the GUI. This should be done whenever one of the info has changed.
The engine can send only selected infos and multiple infos can be send with one info command,
e.g. "info currmove e2e4 currmovenumber 1" or
"info depth 12 nodes 123456 nps 100000".
Also all infos belonging to the pv should be sent together
e.g. "info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv e2e4 e7e5 g1f3"
I suggest to start sending "currmove", "currmovenumber", "currline" and "refutation" only after one second
to avoid too much traffic.
Additional info:
* depth
search depth in plies
* seldepth
selective search depth in plies,
if the engine sends seldepth there must also a "depth" be present in the same string.
* time
the time searched in ms, this should be sent together with the pv.
* nodes
x nodes searched, the engine should send this info regularly
* pv ...
the best line found
* multipv
this for the multi pv mode.
for the best move/pv add "multipv 1" in the string when you send the pv.
in k-best mode always send all k variants in k strings together.
* score
* cp
the score from the engine's point of view in centipawns.
* mate
mate in y moves, not plies.
If the engine is getting mated use negativ values for y.
* lowerbound
the score is just a lower bound.
* upperbound
the score is just an upper bound.
* currmove
currently searching this move
* currmovenumber
currently searching move number x, for the first move x should be 1 not 0.
* hashfull
the hash is x permill full, the engine should send this info regularly
* nps
x nodes per second searched, the engine should send this info regularly
* tbhits
x positions where found in the endgame table bases
* cpuload
the cpu usage of the engine is x permill.
* string
any string str which will be displayed be the engine,
if there is a string command the rest of the line will be interpreted as .
* refutation ...
move is refuted by the line ... , i can be any number >= 1.
Example: after move d1h5 is searched, the engine can send
"info refutation d1h5 g6h5"
if g6h5 is the best answer after d1h5 or if g6h5 refutes the move d1h5.
if there is norefutation for d1h5 found, the engine should just send
"info refutation d1h5"
The engine should only send this if the option "UCI_ShowRefutations" is set to true.
* currline ...
this is the current line the engine is calculating. is the number of the cpu if
the engine is running on more than one cpu. = 1,2,3....
if the engine is just using one cpu, can be omitted.
If is greater than 1, always send all k lines in k strings together.
The engine should only send this if the option "UCI_ShowCurrLine" is set to true.

[shrapnel]

Both SCID-vs-PC and Arena 3.5 show (incorrectly?) that Komodo 9 does not clear hash between moves. The % of hash used continues to grow with each move in a game. Is that what is actually happening or are the two GUIs just not able to accurately report Komodo 9 hash table usage?

The Komodo 9 behavior (if hash is not cleared between moves) is different from Stockfish and every other engine I can think of at the moment. Does this give Komodo 9 an advantage in the programmer's eyes?

This is EXACTLY what is happening even in the very reliable Fritz 13 GUI.
However, the strength of the Engine is very good and there does not APPEAR to be be any loss of ELO.
What's going on ? Is it normal ?

[sockmonkey]

Both SCID-vs-PC and Arena 3.5 show (incorrectly?) that Komodo 9 does not clear hash between moves. The % of hash used continues to grow with each move in a game. Is that what is actually happening or are the two GUIs just not able to accurately report Komodo 9 hash table usage?

The Komodo 9 behavior (if hash is not cleared between moves) is different from Stockfish and every other engine I can think of at the moment. Does this give Komodo 9 an advantage in the programmer's eyes?

The "philosophy" of the UCI protocol is focused on positions. The engine is sent a position and directed to search. During the search, the engine is supposed to send info---info about the search in progress. Stuff like pv, score, nps, etc. Hashfull is included in this info, so the implication is that the number sent represents (an approximation to) the fraction of the hash table filled with entries related to the current search. But the protocol seems imprecise about this---see below. If Komodo is reporting a non-zero hashfull value at the start of a new search, then it seems to be interpreting the protocol differently than intended. At least, that's my (inexpert) opinion.

No. Let's assume that not clearing the hash between moves is deliberate (for all the reasons expressed above), then hashfull needs to report... how full the hash is. Otherwise, Komodo would report (and it used to do this -- we fixed it for K8 IIRC) for the first move, say hashfull 30. For the second move it goes to hashfull 30. For the third move, again to hashfull 30. For the fourth move, it would move from hashfull 0 - hashfull 10. And for every subsequent move, hashfull 0. And you wouldn't have any way of knowing what the current fill state of the hash is, particularly before it's reached capacity (and you just get 0).

The point of the hashfull statistic is to give semi-accurate information about how full the hash is. So starting at 0 and moving toward 100 as the hash fills (even across moves) is the only reasonable implementation.

If the engine is designed to clear the hash for every search, you would see that in the hashfull statistic. As Komodo is not designed that way, the output is IMO correct.

Jeremy

[shrapnel]

No. Let's assume that not clearing the hash between moves is deliberate (for all the reasons expressed above), then hashfull needs to report... how full the hash is. Otherwise, Komodo would report (and it used to do this -- we fixed it for K8 IIRC) for the first move, say hashfull 30. For the second move it goes to hashfull 30. For the third move, again to hashfull 30. For the fourth move, it would move from hashfull 0 - hashfull 10. And for every subsequent move, hashfull 0. And you wouldn't have any way of knowing what the current fill state of the hash is, particularly before it's reached capacity (and you just get 0).

The point of the hashfull statistic is to give semi-accurate information about how full the hash is. So starting at 0 and moving toward 100 as the hash fills (even across moves) is the only reasonable implementation.

If the engine is designed to clear the hash for every search, you would see that in the hashfull statistic. As Komodo is not designed that way, the output is IMO correct.

Jeremy

Thank you for the explanation...was a bit worried initially.
Also, I think Roy Brunjes is correct ; this is giving Komodo an advantage over other Engines. Neat trick !

[sockmonkey]

I really don't think so, I am not aware of other top engines which clear the hash every time they receive a new position. If you examine Stockfish's code, for instance, you'll see that it only clears on 'ucinewgame', when the hash table is resized, or when 'setoption name Clear Hash' is received.

Jeremy

[Guenther]

No. Let's assume that not clearing the hash between moves is deliberate (for all the reasons expressed above), then hashfull needs to report... how full the hash is. Otherwise, Komodo would report (and it used to do this -- we fixed it for K8 IIRC) for the first move, say hashfull 30. For the second move it goes to hashfull 30. For the third move, again to hashfull 30. For the fourth move, it would move from hashfull 0 - hashfull 10. And for every subsequent move, hashfull 0. And you wouldn't have any way of knowing what the current fill state of the hash is, particularly before it's reached capacity (and you just get 0).

The point of the hashfull statistic is to give semi-accurate information about how full the hash is. So starting at 0 and moving toward 100 as the hash fills (even across moves) is the only reasonable implementation.

If the engine is designed to clear the hash for every search, you would see that in the hashfull statistic. As Komodo is not designed that way, the output is IMO correct.

Jeremy

Thank you for the explanation...was a bit worried initially.
Also, I think Roy Brunjes is correct ; this is giving Komodo an advantage over other Engines. Neat trick !

Hu? No normal engine clears hash between moves in game mode.

Guenther

[shrapnel]

I really don't think so, I am not aware of other top engines which clear the hash every time they receive a new position. If you examine Stockfish's code, for instance, you'll see that it only clears on 'ucinewgame', when the hash table is resized, or when 'setoption name Clear Hash' is received.

Jeremy

OK, OK, I get you.
But for whatever reason Komodo 9 seems to find the correct move much faster than before. Also the kN/s keeps increasing rapidly throughout the game and much greater Depth is being achieved.

[sockmonkey]

Yes, that's a direct result of Mark and Larry's mad mojo.

[shrapnel]

[mjlef]

I know of no program that actually clears the hash table between moves. This would severely degrade play since the hash has so much useful information. Now I suspect these other programs are just resetting a kind of counter used to estimate how much of the hash table is being used. The whole hash full thing is actually estimated. Komodo resets this when the hash is actually cleared (this can be done by the user, and automatically happens when a search changing parameter changes, like switching to Chess960 or changing Null move). I feel the Komodo method is the accurate one. Note a lot of programs do not even bother to report the hashfull information.