Pawn table does not help

[Henk]

Actually I tried pawn table four times before. Always same conclusion. It doesn't help very much. Evaluating pawns is too costly for Skipper because there are too many of them. Counting them is the maximum otherwise speed drops significantly.

[hgm]

Counting pieces is usually done incrementally, by just keeping track of what you capture. The whole idea of having a Pawn hash table is that it doesn't matter how much time it takes evaluating Pawn structure, as you just look it up in the table. So the only cost of Pawn eval is updating a Pawn hash key similar to your normal hash key, except that all other pieces now have key 0. Then the whole Pawn evaluation will consist of just reading it from the table, after checking the stored signature matches the key (which almost always will be the case). Only in the rare case that the signature is different, you have to overwrite the entry with newly calculated scores (and signature) before proceding.

[Henk]

Initially the pawn table is empty. So you first have to get these expensive pawn evaluations into the table. Maybe if you fill the pawn table from start with values from a database but I think there are too many of them. Also these table look-ups without a hit cost too much.

[Joost Buijs]

Initially the pawn table is empty. So you first have to get these expensive pawn evaluations into the table. Maybe if you fill the pawn table from start with values from a database but I think there are too many of them. Also these table look-ups without a hit cost too much.

Indeed, you first have to fill it with expensive evaluations.
Because the pawn configuration doesn't change much during a search you will see very high hit-rates.
In my engine I gain about 10% speed-wise due to the pawn table.
I also store the location of passed pawns in the table because they interact very heavily with the pieces surrounding them.
In a new engine I'm working on, I also store the location of backward pawns.

[hgm]

Initially the pawn table is empty. So you first have to get these expensive pawn evaluations into the table. Maybe if you fill the pawn table from start with values from a database but I think there are too many of them. Also these table look-ups without a hit cost too much.

You should have a pretty high hit rate, if your table isn't too small. 1MB is already reasonable, and for me causes a miss rate of about 5-8% in the early middle game (and almost none in the end-game). So you use every calculated value 12-20 times, effectively reducing the cost of calculation with that factor. The cost of misses is hardly a concern, if you only have 5% of them. Access is much cheaper as for the TT, as 1MB easily fits in the L2/L3 cache.

[Henk]

If you already do expensive pawn evaluations, pawn table may help. But it's much faster to not evaluate pawns at all. If Skipper loses too much speed it will play much worse at blitz games. So it looks like it has to skip pawn evaluations. Counting them is the maximum.

Don't know when I will be stupid enough to implement pawn table for the fifth time. Also clearing pawn table is necessary otherwise it runs out of memory.

[Henk]

Don't know maybe if your engine uses zobrist key and pawn hash table is fast too it might work. In my current implementation building keys comparing them and cleaning up pawn table is slow.

Also fastest is not to do pawn evaluations at all. Although passed pawns are important.

[cdani]

As a global example of speed of evaluation, Andscacs is maybe 3 MN/s with very simple evaluation in my main computer, and 1,2 MN/s with the current evaluation. But the difference of course is the later is maybe 400 elo stronger.

[Henk]

As a global example of speed of evaluation, Andscacs is maybe 3 MN/s with very simple evaluation in my main computer, and 1,2 MN/s with the current evaluation. But the difference of course is the later is maybe 400 elo stronger.

If an engine is slow and has a minimal evaluation making it significantly slower with a less minimal evaluation does not help. Maybe making it very slow with a moderate evaluation might help but I doubt that too.

[Volker Annuss]

Don't know maybe if your engine uses zobrist key and pawn hash table is fast too it might work. In my current implementation building keys comparing them and cleaning up pawn table is slow.

Of course you need icrementally updated zobrist keys for the pawn configuration to make a pawn hash table work. When building keys takes more time than pawn eval, the pawn hash table is not useful.

There is no need to clean up a pawn table.

Here are some miss rates for my pawn hash. Size is number of entries, not number of bytes.

Code: Select all

                           miss rate   miss rate
                           size=512    size=8192
initial position              16,4%         9,6%
position after 1. e4 e5       16,1%         9,9%
mix of many positions          7,1%         3,1%

As you can see, you can get low miss rates even for small pawn hash tables.