r2qk2r/ppp2ppp/2b5/4N3/1b1Pp3/8/PPP1QPPP/R1B2RK1 b k - 1 11

...and records the total positions searched to a depth of 5.

SharpChess's total moves search comes to: 52931

The unit test returns a fail, if the number of position exceed 52931, which is the smallest number I've managed to get it down to.

The question is, does this number seem too high?

FYI

SharpChess search uses the following techniques:

- Aspiration search, 3 decreasing windows (1000=1 pawn): +-2000, +- 500, then a zero window.
- PVS Seach.
- Adaptive Null-Nove Forward Pruning (R = depth > 6 ? 3 : 2).
- Quiescence for captures and promotions.
- Search Extensions:
- Check Evasion.
- Single response.
- Pawn push to 7th rank.
- Re-capture of same-value piece.
- Search Reductions:
- Reduce by 1 when alpha > increasing depth-based margin (0, 0, 0, 5000, 5000, 7000, 7000, 9000, 9000, 15000...)
- Futility Pruning at depth 2 where LazyEval + 3000 <= alpha.
- Extended Futility Pruning at depth 3 where LazyEval + 5000 <= alpha.
- Razoring at depth 4 where LazyEval + 9750 <= alpha.

Move ordering is assigned as follows:

- Best move from hash table.
- Pawn Promotion Queen.
- Pawn Promotion Rook.
- Pawn Promotion Bishop.
- Pawn Promotion Knight.
- Static Exchange Evaluation result, highest captures first.
- History Heuristic.
- Killer Move A.
- Killer Move B.
- Static Exchange Evaluation result, losing captures in reverse value order.

I found that the killer moves had very impact on move ordering compared to the history heuristic, which seems to do all the work. I also tried piece-square values, but that didn't do anything for me.