Search with transposition table

[User923005]

I will take a look at it but it probably won't happen until tomorrow.

[hyatt]

some statistics:

fen startpos

-without transposition table:

info string ply: 8 ...
info score cp 61 depth 8 nodes 38901210 time 109935 pv d2d4 d7d5 e2e3 g8f6 b1c3 b8c6 f1b5 d8d6
info string tot moves: 38.901.210


-with transposition table:

info string ply: 8 ...
info score cp 61 depth 8 nodes 19828751 time 59251 pv d2d4 d7d5 e2e3 g8f6 b1c3 b8c6 f1b5 d8d6
info string tot moves: 19.828.751
info string hash_record: 945.371
info string n_cut_hash: 330.107
info string hash_collisions: 636.288

what about numbers?
the n_cut_hash is poor?
the hash_collisions is high?

How big is the table? 945K positions? You MUST have collisions if you search 20M nodes or more... The number of cutoffs is normal for opening. Try fine #70 and you can get a quick feel for whether your tt is working or not. Without TT, depth will go VERY slowly. With TT, you can hit 40+ plies instantly...

[syzygy]

As far as I can tell, the hash move is not tried first. Certainly in the opening and middle game not trying that move first reduces the benefits of a hash table.

You are retrieving the move from hash in case of an EXACT hit in order to add it to the pv, but that is not the reason for storing moves in the hash table. The reason for storing moves is to (greatly) improve move ordering and thereby search efficiency. (It can also save the program some work if it doesn't generate moves until after it has tried the hash move.)

[geko]

some test on 20M nodes TT and 70M nodes TT

fen: r1bn1rk1/ppp1qppp/3pp3/3P4/2P1n3/2B2NP1/PP2PPBP/2RQK2R w K -

no TT
info string ply: 7 ...
info score cp 40 depth 7 nodes 109074744 time 413715 pv c3d4 e6e5 d4e3 c8f5 f3h4 e7d7 h4f5
info string millsec: 413.715 (263.647 nodes per seconds)
info string tot moves: 109.074.744
info string hash_record: 0
info string n_cut_hash :0
hash_collisions: 0



20M nodes TT
info string ply: 7 ...
info score cp 40 depth 7 nodes 82123838 time 322704 pv c3d4 e6e5 d4e3 c8f5 f3h4 e7d7 h4f5
info string millsec: 322.704 (254.486 nodes per seconds)
info string tot moves: 82.123.838
info string hash_record: 548.726
info string n_cut_hash :79.160
hash_collisions: 104.984



70M nodes TT
info string ply: 7 ...
info score cp 40 depth 7 nodes 82071403 time 327145 pv c3d4 e6e5 d4e3 c8f5 f3h4 e7d7 h4f5
info string millsec: 327.145 (250.871 nodes per seconds)
info string tot moves: 82.071.403
info string hash_record: 554.131
info string n_cut_hash :79.693
hash_collisions: 99.011



(hash_record are the nodes stored in TT)
-numbers in TT 20M and 70M are similar, and time too; what about gain? is it bad?
-is there a methodology to test transposition table?

[syzygy]

Maybe you can comment on the issue (that I see) of not trying the hash move first.