Ratio of Transposition Hash to Eval Hash

[JVMerlino]

Since GUIs (as far as I'm aware) only request a single amount of hash memory from an engine, how do engines allocate that amount between transposition hash and eval hash? I'm playing around with different ratios and I have a suspicion that the faster the time control is, the more eval hash you want (particularly if your engine uses NN).

Perhaps a better way of asking the question is "what is the ratio of the number of buckets for the two hash types". My (so far inconclusive) testing is showing that having twice as many eval hash buckets performs the best at typical engine testing tc (I use one minute with no increment). No idea if that would be detrimental at the longer tcs that CCRL uses, for example.

Thoughts?

[flok]

Since GUIs (as far as I'm aware) only request a single amount of hash memory from an engine, how do engines allocate that amount between transposition hash and eval hash? I'm playing around with different ratios and I have a suspicion that the faster the time control is, the more eval hash you want (particularly if your engine uses NN).

Perhaps a better way of asking the question is "what is the ratio of the number of buckets for the two hash types". My (so far inconclusive) testing is showing that having twice as many eval hash buckets performs the best at typical engine testing tc (I use one minute with no increment). No idea if that would be detrimental at the longer tcs that CCRL uses, for example.

Thoughts?

(what is the difference between transposition hash and eval hash?)

[JVMerlino]

Since GUIs (as far as I'm aware) only request a single amount of hash memory from an engine, how do engines allocate that amount between transposition hash and eval hash? I'm playing around with different ratios and I have a suspicion that the faster the time control is, the more eval hash you want (particularly if your engine uses NN).

Perhaps a better way of asking the question is "what is the ratio of the number of buckets for the two hash types". My (so far inconclusive) testing is showing that having twice as many eval hash buckets performs the best at typical engine testing tc (I use one minute with no increment). No idea if that would be detrimental at the longer tcs that CCRL uses, for example.

Thoughts?

(what is the difference between transposition hash and eval hash?)

https://www.chessprogramming.org/Transposition_Table
https://www.chessprogramming.org/Evaluation_Hash_Table

[Joerg Oster]

Since GUIs (as far as I'm aware) only request a single amount of hash memory from an engine, how do engines allocate that amount between transposition hash and eval hash? I'm playing around with different ratios and I have a suspicion that the faster the time control is, the more eval hash you want (particularly if your engine uses NN).

Perhaps a better way of asking the question is "what is the ratio of the number of buckets for the two hash types". My (so far inconclusive) testing is showing that having twice as many eval hash buckets performs the best at typical engine testing tc (I use one minute with no increment). No idea if that would be detrimental at the longer tcs that CCRL uses, for example.

Thoughts?

If you also save the static eval of a position into the Transposition Table, you don't need a separate eval hash.
Almost everybody is doing it this way nowadays ...

[JVMerlino]

Since GUIs (as far as I'm aware) only request a single amount of hash memory from an engine, how do engines allocate that amount between transposition hash and eval hash? I'm playing around with different ratios and I have a suspicion that the faster the time control is, the more eval hash you want (particularly if your engine uses NN).

Perhaps a better way of asking the question is "what is the ratio of the number of buckets for the two hash types". My (so far inconclusive) testing is showing that having twice as many eval hash buckets performs the best at typical engine testing tc (I use one minute with no increment). No idea if that would be detrimental at the longer tcs that CCRL uses, for example.

Thoughts?

If you also save the static eval of a position into the Transposition Table, you don't need a separate eval hash.
Almost everybody is doing it this way nowadays ...

Ok, I'll give that a try. Thanks Joerg!