Pawn hash table, a little disappointment

[hgm]

Pawn + King hash but not really storing King things for now

But that explains the low hit rate.

[xr_a_y]

I'm using a total size for this table that is 1/16 of the TT.
The table is well used, often there is a ratio of 10 read for only 1 write.

But this is a slowdown of about 10% in knps !

I wonder how others engines behave ?

There must be something wrong with your code. I would have a look but it seems that it isn't in your github?
I remember that I got a visible speed up when I introduced pawn hash. My entry is 96 bytes.

The code is up to date on master branch. The entry size is now 68, i'm using 2Mb pawn table, always replace, using king+pawn hash.
Still not better than without table.

A side effect of this is that I found some issues in eval, but to my surprise, correcting them is not good ... (but correction is present on master as they are logical).

[RubiChess]

This line in your ::eval() seems strange:

if (!getPawnEntry(*this, computePHash(p), pePtr)) { ...

Seems that by calling computePHash(p) you recalculate the complete pawnhash from scratch?
I checked that you already do "delta-hashing" in your movepiece so recalculating should not be necessary and may cost too much time.
Another strange thing: Even in your applyNull() the ph (pawnhash?) is changed. Why that?

[xr_a_y]

This line in your ::eval() seems strange:

if (!getPawnEntry(*this, computePHash(p), pePtr)) { ...

Seems that by calling computePHash(p) you recalculate the complete pawnhash from scratch?
I checked that you already do "delta-hashing" in your movepiece so recalculating should not be necessary and may cost too much time.
Another strange thing: Even in your applyNull() the ph (pawnhash?) is changed. Why that?

Pawn hash (as well as position hash) are computed on the fly in apply or applyNull and computeHash will early return if already computed

Code: Select all

if (p.ph != 0ull) return p.ph;

applyNull is xoring zobrist key for color and possible ep but this is bad design (this is because eval is returning score from stm point of view).
In a way, assuming symetric eval, this is probably loosing half of TT ...

[xr_a_y]

This line in your ::eval() seems strange:

if (!getPawnEntry(*this, computePHash(p), pePtr)) { ...

Seems that by calling computePHash(p) you recalculate the complete pawnhash from scratch?
I checked that you already do "delta-hashing" in your movepiece so recalculating should not be necessary and may cost too much time.
Another strange thing: Even in your applyNull() the ph (pawnhash?) is changed. Why that?

Pawn hash (as well as position hash) are computed on the fly in apply or applyNull and computeHash will early return if already computed

Code: Select all

if (p.ph != 0ull) return p.ph;

applyNull is xoring zobrist key for color and possible ep but this is bad design (this is because eval is returning score from stm point of view).
In a way, assuming symetric eval, this is probably loosing half of TT ...

Not taking color into account in pawn hash is currently under test.

[RubiChess]

Pawn hash (as well as position hash) are computed on the fly in apply or applyNull and computeHash will early return if already computed

Code: Select all

if (p.ph != 0ull) return p.ph;

applyNull is xoring zobrist key for color and possible ep but this is bad design (this is because eval is returning score from stm point of view).
In a way, assuming symetric eval, this is probably loosing half of TT ...

Okay. Missed that first line in computePHash.
And the side2move dependant hash is probably not the (only) reason for performing bad.
Will have another look...

Andreas