Conversion to bitboards: comparative statistics

[Chessnut1071]

Comparative statistics: Comparison of methods for solution of 60 6-ply classic check mate puzzles from Kenneth Thompson’s Classic Chess Puzzles.

All data in release mode, C# Net 7.0, wpf, and Intel i7, 2.6 GHz.

Integer move array tables: time to solution: 81.9657 sec; total legal engine calls = 239,738

Bitboard PEXT 64-bit array tables: time to solution: 1.2374746 sec; total legal engine calls = 254,808
• PEXT was about 8% faster than magic bitboards on pseudo move generation; however, once array data were taken for legal moves, that
difference is insignificant. Also, PEXT did not have collisions like magic numbers and required no adjustments.

Breakdown of engine call requirements:
Alpha/beta: time to solution = 4.8570267 sec; total engine calls = 983, 856
Alpha/ beta + Zobirst Hash: time to solution = 4.1935166 sec; engine calls = 818,638
Alpha/beta + Zobirst + Evaluation: time to solution = 1.2374746; engine calls = 254,808

Evaluation metrics:
1. Check: single =1; discovered check = 2; double check = 3
2. Capture: piece type P=1; N = 2; B = 3; R = 4; Q = 5; K = 6
3. History: # of successes by ply
4. Ent passant
5. Pawn promotion

Legal move data:
a. Piece
b. Move
c. Capture
d. Direction ray
e. Check 1,2,3
f. From
g. To
h. Check direction
i. Skip move bit
j. Pawn promotion to, type
k. Two-step pawn move e.p. target
l. Ent passant move

Although bitboard can produce 10's of million pseudo moves per second, eventually you need to extract relevant move data for legal moves. I need 52-bits for the legal move data and 11 bits for the evaluation metric. Everything fits into one 64-bit variable which makes for a fast evaluation sort.

I'd be interested in hearing how to improve upon the above. I'm not going to C++, although I said that about C# last year.

[dangi12012]

With pext there is no requirement to put the target BB into the ~1M slots. You can put a struct there that contains your movelist, zobrist delta etc.

This is one advantage of the slot lookups have over raw bitlevel calculation.
If your move also contains check information you would have to enrich that bit via (target & EnemyKing != 0) << bitpos at runtime.

Generally its a good idea to stick for moves to a 16 bit format.