TalkChess.com

Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

Alvaro

Of course since all of this happens so far from the root, any collisions may have very little impact on the final propagated score/pv.

Alvaro

Cardoso wrote:Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

I think this is fine from what I remember with Jazz and SjaakII, but I wonder why you'd need 32 bits to store the evaluation score...

Evert wrote:

Cardoso wrote:Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

I think this is fine from what I remember with Jazz and SjaakII, but I wonder why you'd need 32 bits to store the evaluation score...

If 8 byte alignment, then no loss because of padding anyway.

Dann Corbit wrote:

Evert wrote:

Cardoso wrote:Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

I think this is fine from what I remember with Jazz and SjaakII, but I wonder why you'd need 32 bits to store the evaluation score...

If 8 byte alignment, then no loss because of padding anyway.

Sure, you want one entry in 64 bits, but if you use 16 bits for the evaluation result you can use 48 bits for the lock.

Evert wrote:

Dann Corbit wrote:

Evert wrote:

Cardoso wrote:Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

I think this is fine from what I remember with Jazz and SjaakII, but I wonder why you'd need 32 bits to store the evaluation score...

If 8 byte alignment, then no loss because of padding anyway.

Sure, you want one entry in 64 bits, but if you use 16 bits for the evaluation result you can use 48 bits for the lock.

Depending on how many entries you have the extra bits may be overkill.

I tend to use a much simpler eval hash, but I am sure that Bob tested it carefully.

Dann Corbit wrote: Depending on how many entries you have the extra bits may be overkill.

I tend to use a much simpler eval hash, but I am sure that Bob tested it carefully.

Sure, but the original question was whether 48 bits (32 lock + 16 index) is enough; as you say I'm sure Bob tested that this was fine, but I don't see why you couldn't have 64 bits (48 lock + 16 index) by storing the evaluation result in 16 bits rather than 32.
Of course if it's redundant it neither helps no hurts, so the question is entirely academic.

It probably would not even hurt if you did 16 bit key + 16 bit eval. But that would need to be confirmed by testing.

With 32 bits of key you would have a false hit only once every 4 billion probes, i.e. at 4Mnps once very 1000 sec. You have to compare that extra probability to get an eval that is totally off to the ~1% of the leave nodes that have evals that are totally off for search-related reasons (e.g. because a 'bad capture' turned out not to be bad at all due to soft-pinning or overloading of one of the involved pieces). So you would drive up the error rate from 1% to 1.000000025%...

Cardoso wrote:Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

Alvaro

More than enough. First, a collision won't crash a thing. Based on the paper Cozzie and I wrote a few years back on hash collisions, even one in a million bad hashes won't do a thing, and the collision rate won't be anywhere near that...

Also notice that less than 1/2 of the positions get stored anyway. If there is a lazy exit, we don't store a thing.

Evert wrote:

Cardoso wrote:Hi,
I noticed crafty 25 has an eval hash table.
It uses 32 bits from the upper part of the hashkey plus 16 bits from the hash size (65536), this is 48 bits total, do you think this is enough?
I understand it is nice to have 64 bits for the eval hash entries (32 for key + 32 for score), but 48 bits for the key seems a bit risky.

I think this is fine from what I remember with Jazz and SjaakII, but I wonder why you'd need 32 bits to store the evaluation score...

It was simple. I tried several versions, including storing the score, the bounds, and what the current score means (score from lazy1, lazy2 or full eval. There was no benefit. Mike kept fiddling with it and this was worth a couple of elo, just doing the simple "only store full evals". But we did not go back to trying to recover the 16 bits we no longer needed. I might do that at some point, but the rise is close enough to zero...