Pawn table does not help

[Henk]

Ok no zobrist key no pawn table. So that means no pawn table possible for Skipper.

By the way when I did not clean pawn table my engine crashed because there was not memory enough.

[jdart]

By the way when I did not clean pawn table my engine crashed because there was not memory enough.

You should not be dynamically allocating (via "new" or "malloc") the pawn hash table entries, and probably not the pawn hash table itself. That will be slow. My table is just an array (see https://github.com/jdart1/arasan-chess/ ... /scoring.h around line 90).

--Jon

[bob]

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.

How can you "not evaluate pawns at all" and still play anything even close to reasonable chess?

[bob]

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.

If you do pawn hashing right, even if you get zero hits, the speed impact is minimal. I assume you are using the usual Zobrist hashing? I just keep two hash signatures, one with all pieces and pawns, used in the normal transposition table probes, and one with just pawns, used to probe the pawn hash table. One memory access is not going to be much of a deal here. Not doing a pawn evaluation is going to get you killed in chess games.

[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.

If you do pawn hashing right, even if you get zero hits, the speed impact is minimal. I assume you are using the usual Zobrist hashing? I just keep two hash signatures, one with all pieces and pawns, used in the normal transposition table probes, and one with just pawns, used to probe the pawn hash table. One memory access is not going to be much of a deal here. Not doing a pawn evaluation is going to get you killed in chess games.

Skipper does not use Zobrist hashing. So creating and comparing keys is not for free.

[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.

How can you "not evaluate pawns at all" and still play anything even close to reasonable chess?

With material counting plus random value an engine is strong enough to beat me. Perhaps if evaluation is worthless, evaluating sixteen pawns does not help.

[Sven]

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.

If you do pawn hashing right, even if you get zero hits, the speed impact is minimal. I assume you are using the usual Zobrist hashing? I just keep two hash signatures, one with all pieces and pawns, used in the normal transposition table probes, and one with just pawns, used to probe the pawn hash table. One memory access is not going to be much of a deal here. Not doing a pawn evaluation is going to get you killed in chess games.

Skipper does not use Zobrist hashing. So creating and comparing keys is not for free.

Then how do you maintain a hash key? Incrementally, or always from scratch after making a move?

[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.

If you do pawn hashing right, even if you get zero hits, the speed impact is minimal. I assume you are using the usual Zobrist hashing? I just keep two hash signatures, one with all pieces and pawns, used in the normal transposition table probes, and one with just pawns, used to probe the pawn hash table. One memory access is not going to be much of a deal here. Not doing a pawn evaluation is going to get you killed in chess games.

Skipper does not use Zobrist hashing. So creating and comparing keys is not for free.

Then how do you maintain a hash key? Incrementally, or always from scratch after making a move?

Not incrementally. Good idea. Maybe that's the first thing to change. But there are many other pieces of code to improve. In my current implementation I did not do table look-ups near the leaves just to make sure it would not become a performance bottleneck.

[Sven]

In my current implementation I did not do table look-ups near the leaves just to make sure it would not become a performance bottleneck.

Why should a hash table lookup that helps to avoid searching again many subtrees, and/or helps to improve move ordering, become a performance bottleneck?

EDIT: here I assume your remark was about TT lookup, since you previously wrote that your current implementation does not include a pawn hash table.

[Henk]

In my current implementation I did not do table look-ups near the leaves just to make sure it would not become a performance bottleneck.

Why should a hash table lookup that helps to avoid searching again many subtrees, and/or helps to improve move ordering, become a performance bottleneck?

EDIT: here I assume your remark was about TT lookup, since you previously wrote that your current implementation does not include a pawn hash table.

Perhaps it doesn't but I wanted to make sure it certainly does not. Also I was focusing on nodes/second because Skipper was five times slower than fairy-max.