Pawn hash table, a little disappointment

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 23725
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Pawn hash table, a little disappointment

Post by hgm » Mon Oct 28, 2019 9:14 pm

xr_a_y wrote:
Mon Oct 28, 2019 8:19 pm
Pawn + King hash but not really storing King things for now
But that explains the low hit rate.

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Pawn hash table, a little disappointment

Post by xr_a_y » Thu Oct 31, 2019 9:26 am

RubiChess wrote:
Mon Oct 28, 2019 4:27 pm
xr_a_y wrote:
Mon Oct 28, 2019 6:05 am
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
Posts: 114
Joined: Fri Mar 30, 2018 5:20 am

Re: Pawn hash table, a little disappointment

Post by RubiChess » Thu Oct 31, 2019 2:56 pm

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?

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Pawn hash table, a little disappointment

Post by xr_a_y » Thu Oct 31, 2019 4:24 pm

RubiChess wrote:
Thu Oct 31, 2019 2:56 pm
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 ...

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Pawn hash table, a little disappointment

Post by xr_a_y » Thu Oct 31, 2019 4:52 pm

xr_a_y wrote:
Thu Oct 31, 2019 4:24 pm
RubiChess wrote:
Thu Oct 31, 2019 2:56 pm
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
Posts: 114
Joined: Fri Mar 30, 2018 5:20 am

Re: Pawn hash table, a little disappointment

Post by RubiChess » Thu Oct 31, 2019 4:53 pm

xr_a_y wrote:
Thu Oct 31, 2019 4:24 pm
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

Post Reply