Komodo 9 and hash table usage

[mjlef]

I confess find that field nearly useless. I use it once for setting hash size. I also confess that I have used it for other things while developing a chess engine. For example, I wanted to see how good my chess program was at searching the best move first when there was a best move. Just take over hashfull and it can report that as a convenient percentage. And it works in most GUIs already.

[syzygy]

Unfortunately, the existing UCI standards do not address what this is supposed to mean. Should it be the percentage of hash table used on a given move, or the percentage of the total hash used? I do not have a strong opinion either way. The only use we make of it is in trying to set an optimum size for the Hash table.

Since not somehow "resetting" the value between moves will always make it go to 99 quickly and stay there for the remainder of the game, and since many users get very upset by a value of 99 and might even fear it hurts their hardware, it seems to me the intended behaviour is to reset it between moves.

But I would recommend not reporting it at all. It is such a completely useless number.

[sockmonkey]

But resetting it between moves will make it peg at 0 once the hash is filled. So it's a no-win situation.

[hgm]

Reporting the entries accessed during the current search and the one directly preceding it, as I described, would have neither of these problems. It won't go to 0, and it won't converge to 100 by indefinite accumulation.

[sockmonkey]

Reporting the entries accessed during the current search and the one directly preceding it, as I described, would have neither of these problems. It won't go to 0, and it won't converge to 100 by indefinite accumulation.

That may be so, but I wouldn't hazard to describe that as a reasonable interpretation of the (admittedly vaguely) specified protocol.

[hgm]

I think it would be the most reasonable interpretation: you count exactly that what might still prove useful (used in the previous search, which might perhaps yet be visited in the current one), and you discount what has been 'proven' useless by not having been visited in the (completed) previous search.

How could counting something that was shown not to be relevant anymore in the previous search, or not counting something that was relevant then, and has not yet shown to be not needed anymore, be considered "more reasonable"?

[sockmonkey]

I know you refuse to admit error and won't back down, so I won't argue with you. I'll leave it to you to justify your implementation against the protocol's specification:

Code: Select all

	* hashfull <x>
		the hash is x permill full, the engine should send this info regularly

How does your arbitrary usefulness test in any way satisfy "the hash is x permill full"?

jb

[zullil]

I know you refuse to admit error and won't back down, so I won't argue with you. I'll leave it to you to justify your implementation against the protocol's specification:

Code: Select all

	* hashfull <x>
		the hash is x permill full, the engine should send this info regularly

How does your arbitrary usefulness test in any way satisfy "the hash is x permill full"?

jb

At this point, the consensus seems to be that the specification is unclear, and that the information itself is of little or no value.

My original point was that "hashfull" is included as an item under "info" in the specification. Other such items in this list include "nodes" and "tbhits".
Are these typically reported as totals accumulated from the start of the game? No. They are zeroed at the start of the current search.

In any case, it's clear the "specification" isn't one. (And I wonder why hashfull was specified as "permill" rather than "percent". Aren't two significant figures enough? Why not four?)