Two to the eighteenth

[sje]

I've been doing some testing of the new Symbolic core and have noted something that I should have seen long ago: the number of distinct pawn structures seen in searches in a game will be somewhat less than a quarter million. Well, on average. So this means that the pawn structure transposition table doesn't need to have more than 2^18 (262,144) entries. This figure is for a table that is cleared at the beginning of a game but is otherwise persistent from move to move.

A larger number of entries might be useful for a pawn structure table that is persistent across sequential games. It might even be worthwhile to store/restore the pawn transposition table to/from disk between sessions. On the other hand, I'd guess that a small, move-to-move table with only 2^16 entries will deliver 99% of all possible benefit.

[Onno Garms]

Interesting.

Some time ago I also made attempts to count the number of pawn structures in a search. (I think I did it with a hash table that never overwrites, but uses the next free entry, starting at the entry associated to the key. The table size is doubled each time when the table is more then 50% full.)

My results were significantly different from yours:
1 M nodes searched => 67 k pawn structures
10 M nodes searched => .5 M pawn structures
100 M nodes searched => 1-2 M pawn structures
The number of pawn structures is per search not for the whole game like in your experiments.

I also found that enlarging the pawn hash to more then 2^14 did not result in a speedup in practice.

[sje]

The total count of unique searched pawn structures will be dependent in part on the depth of the individual searches. I'll guess that the searches in your test were move extensive than those in my blitz searches.

Another issue affecting the pawn structure count is the opening book in use. An extensive opening book will bring the program past a large portion of possible pawn structures.