What is the Difference between Mainhash, Evalhash, Pawnhash?

[Thomas Wallendik]

Hello,

in the Engineoptions of many Engines i can set a Size of Mainhash, Evalhash, Pawnhash, what is the Difference to te classical Variation, only one Size für Hashtables for a Engine, as example 512 Megabytes?

Why i need Mainhash, Evalhash, Pawnhash and whitch Size of Hashtables for Hiarcs is the best on a Personalcomputer with 2048 Megabytes RAM?

In my Round-Robin-Tournaments i set 512 Megabytes for an Engine and i think, this is a very good Size. But i only let play my tournaments with 40 Moves in 180 Minutes. It gives Engines, whitch fuel the Hashtables very fast and a Hashkollision comes then.

I have read in the Internet, that the Tablebases are very good, when they are fuelled with 75 %. Is this right?

Best wishes

Thomas Wallendik

[bob]

Hello,

in the Engineoptions of many Engines i can set a Size of Mainhash, Evalhash, Pawnhash, what is the Difference to te classical Variation, only one Size für Hashtables for a Engine, as example 512 Megabytes?

Why i need Mainhash, Evalhash, Pawnhash and whitch Size of Hashtables for Hiarcs is the best on a Personalcomputer with 2048 Megabytes RAM?

In my Round-Robin-Tournaments i set 512 Megabytes for an Engine and i think, this is a very good Size. But i only let play my tournaments with 40 Moves in 180 Minutes. It gives Engines, whitch fuel the Hashtables very fast and a Hashkollision comes then.

I have read in the Internet, that the Tablebases are very good, when they are fuelled with 75 %. Is this right?

Best wishes

Thomas Wallendik

mainhash is the normal transposition/refutation table, that stores scores/bounds for nodes that have been searched already.

pawn hash stores just pawn scores and uses just the positions of pawns to compute the hash signature. It avoids having to repeatedly evaluate the same pawn structure over and over since most moves in the game of chess are piece moves only.

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

[Ryan Benitez]

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

I am open to the possibility that an engine that does not hash qsearch nodes could get some gain from a separate eval hash.

[Uri Blass]

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

I am open to the possibility that an engine that does not hash qsearch nodes could get some gain from a separate eval hash.

I can say that I use all these types of hash and all are productive.

main hash is the only hash that can change the tree.
eval hash and pawn hash are only about making the program faster.

Note that movei evaluates every node and not only the leaves because the evaluation may be relevant to search decisions.

I do not hash qsearch nodes but I do not think that it is relevant for the fact that for me there is a gain from evaluation hash.

evaluation hash cannot be part of the main hash because the main hash often has bounds and not exact evaluation of the position and the evaluation hash simply give exact number that is the evaluation of the position.

Uri

[pedrox]

Eval hash is good for me, it gives a 5% rapid with the same tree. In the evaluation, I first check lazy eval and then eval hash.

Pedro

[Mark Uniacke]

Hello,

in the Engineoptions of many Engines i can set a Size of Mainhash, Evalhash, Pawnhash, what is the Difference to te classical Variation, only one Size für Hashtables for a Engine, as example 512 Megabytes?

Why i need Mainhash, Evalhash, Pawnhash and whitch Size of Hashtables for Hiarcs is the best on a Personalcomputer with 2048 Megabytes RAM?

In my Round-Robin-Tournaments i set 512 Megabytes for an Engine and i think, this is a very good Size. But i only let play my tournaments with 40 Moves in 180 Minutes. It gives Engines, whitch fuel the Hashtables very fast and a Hashkollision comes then.

I have read in the Internet, that the Tablebases are very good, when they are fuelled with 75 %. Is this right?

Best wishes

Thomas Wallendik

mainhash is the normal transposition/refutation table, that stores scores/bounds for nodes that have been searched already.

pawn hash stores just pawn scores and uses just the positions of pawns to compute the hash signature. It avoids having to repeatedly evaluate the same pawn structure over and over since most moves in the game of chess are piece moves only.

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

To answer the original question just use half the physical RAM in your machine as a rule of thumb. As long as there is no swapping to the hard disk it does not matter.

I think the benefit of eval hash depends on how much you apply full eval to the internal nodes of the search tree. If you are mainly evaluating leaves then it has less value. With internal node eval and iterative deepening then it may be useful.

I've never been particularly convinced that pawn hash matters a lot. I guess it depends if programs incrementally update information or compute it from scratch.

From a user's perspective, surely all they are interested in is how much memory is given to the engine, the engine can then allocate that memory how it wishes.

[Thomas Wallendik]

Thank you, for all your answer.

[bob]

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

I am open to the possibility that an engine that does not hash qsearch nodes could get some gain from a separate eval hash.

Think about this: What would be different from the normal hash? The eval depends on every piece, so the eval hash signature needs to have all pieces factored in. If you do that, why not just store the static eval in the hash along with the search result? I did that in early versions of Crafty but later removed it as the eval hash hit percentage is so terribly low it is not very effective, and adding another 32 bit value to the hash entry reduces overall hash size by 25% since my hash entry is 16 bytes long.

I also used to hash q-search nodes, but found in 1996 two important things. Removing it made the search 10% faster, but made the tree 10% larger. So absolutely no effect on speed. But by not hashing the q-search, pressure on the table is much lower and I can get by with a much smaller table, because way over 50% of all nodes searched are q-search, which blows through the hash in no time.

[bob]

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

I am open to the possibility that an engine that does not hash qsearch nodes could get some gain from a separate eval hash.

I can say that I use all these types of hash and all are productive.

main hash is the only hash that can change the tree.
eval hash and pawn hash are only about making the program faster.

Note that movei evaluates every node and not only the leaves because the evaluation may be relevant to search decisions.

If you are doing that, why not just add a 32 bit value to hold the evaluation value, and stick it into the normal hash entry. It would be way faster to do just _one_ hash probe at the front of each node, and retrieve the eval score there as well, rather than having two separate tables, but which need to be indexed by the same hash signature...

Seems like a big waste...

I do not hash qsearch nodes but I do not think that it is relevant for the fact that for me there is a gain from evaluation hash.

evaluation hash cannot be part of the main hash because the main hash often has bounds and not exact evaluation of the position and the evaluation hash simply give exact number that is the evaluation of the position.

Uri

Add a third word of memory to hold the exact evaluation. If you call Evaluate() at _every_ node, just stuff the resulting score into the hash when you write it at the end of each node search. That seems like a simple solution that would be faster.

[Mark Uniacke]

Bob,

That is what Ryan is saying, if you don't hash in qsearch you are not going to get much of anything out of storing eval moves in the hash table because the hit rate will be really small as you highlighted yourself.

As you said most of us don't hash in qsearch but if you did and also performed a lot of full evals at internal nodes in the tree then you might get a small speed up from a cache of eval info but maybe you could use the memory better in other ways like storing more hash entries.

[bob]

Bob,

That is what Ryan is saying, if you don't hash in qsearch you are not going to get much of anything out of storing eval moves in the hash table because the hit rate will be really small as you highlighted yourself.

As you said most of us don't hash in qsearch but if you did and also performed a lot of full evals at internal nodes in the tree then you might get a small speed up from a cache of eval info but maybe you could use the memory better in other ways like storing more hash entries.

I originally hashed everywhere. And I also tried the "eval stored in hash node" trick as well. This was in version 3.8 which is early 1996. I eventually removed it, and did so before I removed qsearch hashing. I don't remember much about why except that I rarely made decisions unless they added smarts or improved performance. I suspect this was a performance issue. Pawn hashing has always been a big win for me, ditto for king safety. I now have king safety and pawn hashing combined which provides even better performance with no loss of information.

[Tony]

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

I am open to the possibility that an engine that does not hash qsearch nodes could get some gain from a separate eval hash.

I can say that I use all these types of hash and all are productive.

main hash is the only hash that can change the tree.
eval hash and pawn hash are only about making the program faster.

Note that movei evaluates every node and not only the leaves because the evaluation may be relevant to search decisions.

If you are doing that, why not just add a 32 bit value to hold the evaluation value, and stick it into the normal hash entry. It would be way faster to do just _one_ hash probe at the front of each node, and retrieve the eval score there as well, rather than having two separate tables, but which need to be indexed by the same hash signature...

Seems like a big waste...

I do not hash qsearch nodes but I do not think that it is relevant for the fact that for me there is a gain from evaluation hash.

evaluation hash cannot be part of the main hash because the main hash often has bounds and not exact evaluation of the position and the evaluation hash simply give exact number that is the evaluation of the position.

Uri

Add a third word of memory to hold the exact evaluation. If you call Evaluate() at _every_ node, just stuff the resulting score into the hash when you write it at the end of each node search. That seems like a simple solution that would be faster.

You're correct of evalhash only returns a value (so the hashtable is used as normal hashtable) What if it's used like a pawnhashtable, giving all kind of extra information ? Maybe even a selection of wich eval code should be used.

Tony

[bob]

eval hash seems to be pointless as it could be incorporated into the normal hash using the same signature, if someone believed it was worthwhile.

I am open to the possibility that an engine that does not hash qsearch nodes could get some gain from a separate eval hash.

I can say that I use all these types of hash and all are productive.

main hash is the only hash that can change the tree.
eval hash and pawn hash are only about making the program faster.

Note that movei evaluates every node and not only the leaves because the evaluation may be relevant to search decisions.

If you are doing that, why not just add a 32 bit value to hold the evaluation value, and stick it into the normal hash entry. It would be way faster to do just _one_ hash probe at the front of each node, and retrieve the eval score there as well, rather than having two separate tables, but which need to be indexed by the same hash signature...

Seems like a big waste...

I do not hash qsearch nodes but I do not think that it is relevant for the fact that for me there is a gain from evaluation hash.

evaluation hash cannot be part of the main hash because the main hash often has bounds and not exact evaluation of the position and the evaluation hash simply give exact number that is the evaluation of the position.

Uri

Add a third word of memory to hold the exact evaluation. If you call Evaluate() at _every_ node, just stuff the resulting score into the hash when you write it at the end of each node search. That seems like a simple solution that would be faster.

You're correct of evalhash only returns a value (so the hashtable is used as normal hashtable) What if it's used like a pawnhashtable, giving all kind of extra information ? Maybe even a selection of wich eval code should be used.

Tony

wouldn't matter IMHO. two separate tables makes little sense since they would both be addressed using the same hash signature. Just add the extra info to the normal hash table and keep on going. Otherwise, if you make the eval hash smaller than the other hash, hit rate goes down and the usefulness drops...

[Tord Romstad]

Add a third word of memory to hold the exact evaluation. If you call Evaluate() at _every_ node, just stuff the resulting score into the hash when you write it at the end of each node search. That seems like a simple solution that would be faster.

This only works if your evaluation function returns a single value. My evaluation hash table contains the evaluation score, king safety scores for both sides, and passed pawn scores for both sides. Stuffing all of this into the main hash table would make the hash table entries far too big. It is better to have a separate, small evaluation hash table.

The evaluation hash table gives me about 5-10% extra speed in fast games, but less in slow games. The main benefit of the evaluation hash table seems to be that many of the internal nodes (I evaluate all internal nodes) at iteration N were already evaluated at iteration N-1.

I am talking about Glaurung 1.x here. The new Glaurung 2 still has only a very rudimentary evaluation function, an evaluation hash table would therefore be pointless.

Tord