Debugging a transposition table

[Joost Buijs]

At the root my engine stores every-PV move and every fail-high, and does this for every iteration. For the remaining part of the tree it only stores at the end of a node.

What is the advange of that?
I did a quick test with my program and it showed a -32 elo with that.

There is no special advantage at all, it just seems the natural way of doing this. That your engine degrades 32 Elo just by changing the way you store the TT entries at the root is strange, or do you mean storing the entries only at the end of each node?

Anyway, it is difficult to compare these concepts between different engines, what for engine 'A' is better can be worse for engine 'B'. In practice it is better to rely on the outcome of automated tests. A gauntlet between your engine and a bunch of other engines of approx. the same strength works best.

[Joost Buijs]

Isn't that very suspect? How can it make the slightest difference what you store in the TT during an iteration? It should be overwritten by what you store when you leave the node. And up to that point it should never have been probed, as any visits to the node during that period should have been repetitions.

It should not have any impact on a single threaded search, but storing entries usually is a very slow process and doing all these redundant stores is not something you would like, and in a multi threaded search it will certainly have an impact on your search as well.

[hgm]

I don't think it would be slow. You store in a bucket that was probed before, so it is very likely to still be in cache. To be flushed out of the cache (even L2) in the time of an iteration you would need a pretty deep search. And nodes with such a deep search are so rare that it doesn't have any impact, no matter how slow it is. A 40-Elo gain roughly corresponds to a 40% speedup...

In SMP the data could indeed be probed, when reached through another path. But was the test that reports this +40 Elo gain one with more than a single core?

[Joost Buijs]

I don't think it would be slow. You store in a bucket that was probed before, so it is very likely to still be in cache. To be flushed out of the cache (even L2) in the time of an iteration you would need a pretty deep search. And nodes with such a deep search are so rare that it doesn't have any impact, no matter how slow it is. A 40-Elo gain roughly corresponds to a 40% speedup...

In SMP the data could indeed be probed, when reached through another path. But was the test that reports this +40 Elo gain one with more than a single core?

+40 Elo seems very high indeed, there probably was something else wrong or missing. I agree that these redundant stores can't have an impact of 40% on speed, also because this only happens at PV nodes which are scarce, but it still is something I try to avoid. When you try to get your engine as strong as possible, each procent of speed that you can gain counts, doing redandant things that are easy to avoid are out of the question in my opinion.

Edit:

In the CPW code snippet shown before an exact entry is stored at the end of each node, even when it is a fail-low, that is probably the reason for the huge Elo gain after correcting this. Maybe that snipped is wrong, I don't know, I never looked at CPW.

[xr_a_y]

Isn't that very suspect? How can it make the slightest difference what you store in the TT during an iteration? It should be overwritten by what you store when you leave the node. And up to that point it should never have been probed, as any visits to the node during that period should have been repetitions.

Research may occur (aspiration windows) and iid for sorting (in absence of TT move) deeper in the tree may encounter the same position I think. I agree so much elo probably means there is something wrong. Also TT insertion when val > alpha was done for all moves until time control set the stopFlag so the last thing added in TT this way may not be the "real" best move because stopFlag when set forbid further insertion in TT and especially the one at the end of the move loop for the current deepening depth.

[Ronald]

Sorry for the late reaction, i was not able to react sooner.
The only way to calculate the exact value or upper bound of a position is to calculate all the moves in the position and then to determine which move created the highest score, if it's inside the alfa beta window it's exact if it's below alfa it's an upper bound. Therefore it's useless to store intermediate results in the hash, because if the first store is not the best, you do stores for nothing. Even though a store might be cheap, doing it for nothing is still an unnecessary cost.

In addition to that it might introduce errors in your search. In a single thread, it might have no influence if your engine checks for a single repetition in alfabeta and quiescence, my engine does not check for repetition in quiescence but uses the hashtable, so when i tested with my engine it did have an effect on the searchtree.

When multi threaded with lazy SMP, different threads will (hopefully) find a lot of identical positions and then intermediate hash values will be found and used, and thus create errors in your search. So there are only reasons not to do it.

I think the pseudo code of Joost describes the right way to do it, i don't understand the CPW code, it looks completely wrong to me.

Considering the depth to use when storing the position in hash, depends on how you do your extension/reductions. In my engine i only do extensions/reductions for a subset of moves in the position and then it doesn't seem right to store the position with a corrected depth. I hadn't looked good enough to the source of Topplechess to realize that in Topplechess every move is extended 1 ply. In that case it might even be better to store it with the corrected depth, because in that case the search really is based on the higher depth.

[konsolas]

I agree that saving a hash value during the move loop isn't very useful. I've moved it to the end of the function as Joost recommends in their pseudocode.

I've also added simple move ordering, based on hash, SEE, killers and history.
For some reason, the search is still as slow as before, even though everything about the transposition table looks like it's being implemented correctly: The hashfull function shows that the table is definitely filling up, and the hash hit rate (successful probes / total probes) is almost 100%, but still the search is taking far longer than expected, and the engine doesn't find a winning score.

Code: Select all

position fen 8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - -
go infinite-
info depth 1 score cp 63 time 0 nodes 7 nps 7000 hashfull 1 hashhitrate 0 mbf 7 betacutoff nan pv a1b2
info depth 2 score cp 23 time 60 nodes 31 nps 0 hashfull 4 hashhitrate 0.2 mbf 6.2 betacutoff 1 pv a1b2 a7b7
info depth 3 score cp 55 time 118 nodes 116 nps 0 hashfull 11 hashhitrate 0.388889 mbf 6.44444 betacutoff 1 pv a1b2 a7b7
 b2c3
info depth 4 score cp 55 time 175 nodes 396 nps 2000 hashfull 38 hashhitrate 0.536585 mbf 4.82927 betacutoff 0.962264 pv
 a1b2 a7b6 b2c3 b6b7
info depth 5 score cp 55 time 236 nodes 1097 nps 4000 hashfull 65 hashhitrate 0.70852 mbf 4.91928 betacutoff 0.923729 pv
 a1b2 a7b6 b2c3 b6a6 c3b3
info depth 6 score cp 54 time 305 nodes 2864 nps 9000 hashfull 126 hashhitrate 0.839695 mbf 3.64377 betacutoff 0.83592 p
v a1b2 a7b7 b2c3 b7c8 c3b3 c8c7
info depth 7 score cp 56 time 364 nodes 6707 nps 18000 hashfull 176 hashhitrate 0.904273 mbf 3.62737 betacutoff 0.876673
 pv a1b1 a7a6 b1c2 a6b6 c2c3 b6a6 c3d2
info depth 8 score cp 55 time 428 nodes 16099 nps 37000 hashfull 239 hashhitrate 0.954657 mbf 3.04156 betacutoff 0.92408
5 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7d7 d3e3 d7e7
info depth 9 score cp 55 time 491 nodes 37328 nps 75000 hashfull 272 hashhitrate 0.972563 mbf 3.75156 betacutoff 0.95101
8 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7d7 d3c4 d7e7 c4c3
info depth 10 score cp 55 time 560 nodes 81243 nps 144000 hashfull 322 hashhitrate 0.987777 mbf 3.07261 betacutoff 0.982
789 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6a7
info depth 11 score cp 55 time 639 nodes 240951 nps 376000 hashfull 366 hashhitrate 0.993847 mbf 4.03745 betacutoff 0.99
0478 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6b6 d3c4
info depth 12 score cp 55 time 759 nodes 552102 nps 726000 hashfull 411 hashhitrate 0.997682 mbf 3.1047 betacutoff 0.997
195 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6b6 d3c4 b6a6
info depth 13 score cp 55 time 958 nodes 1728824 nps 1802000 hashfull 464 hashhitrate 0.998868 mbf 4.19946 betacutoff 0.
998471 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6b6 d3c4 b6a6 c4d3
info depth 14 score cp 55 time 1430 nodes 3877820 nps 2709000 hashfull 545 hashhitrate 0.999561 mbf 3.11021 betacutoff 0
.999475 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6b6 d3c4 b6a6 c4d3 a6b6
info depth 15 score cp 55 time 2403 nodes 12036898 nps 5007000 hashfull 682 hashhitrate 0.999754 mbf 4.30728 betacutoff
0.999588 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6b6 d3c4 b6a6 c4c3 a6b6 c3c4
info depth 16 score cp 55 time 5326 nodes 26802503 nps 5031000 hashfull 920 hashhitrate 0.999892 mbf 3.13075 betacutoff
0.9998 pv a1b1 a7b6 b1c2 b6c7 c2d3 c7b6 d3c4 b6a6 c4d3 a6b6 d3c4 b6a6 c4c3 a6b6 c3b3 b6a7

Is this usually caused by hash cutoffs not working correctly, or is it an issue with move ordering? Everything seems like it's working but the search still doesn't find the win.
I've updated the repository with my new code: https://github.com/konsolas/ToppleChess

[hgm]

For comparison, this is how Fairy-Max (an engine with always-replace TT, (256MB) and no move ordering other than hash-move first) fares on Fine #70:

Code: Select all

	mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
 35	+2.29 	90.7M  	0:56.48	a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c8
 34	+0.46 	36.4M  	0:21.81	a1b1 a7b7 b1a2 b7b8 a2b2 b8c8 b2c2 c8b8 c2b1
 33	+0.45 	36.2M  	0:21.65	a1b1 a7b7 b1b2 b7b8
 33	+0.44 	36.2M  	0:21.65	a1b2 a7b8 b2a2 b8c8 a2b3 c8c7 b3a2
 32	+0.86 	32.5M  	0:19.32	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3e2 b7c8 e2d2 c8c7 d2d1
 32	+0.85 	31.6M  	0:18.82	a1b1 a7b7 b1c1 b7c7 c1d2 c7b6 d2d3 b6c7 d3c3 c7b6 c3c4
 31	+2.23 	18.2M  	0:10.82	a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c8
 30	+2.18 	17.9M  	0:10.62	a1b1 a7a8 b1b2 a8a7 b2b3 a7b7 b3c3 b7c7 c3d3 c7b6 d3d2 b6b7 d2c1
 30	+0.91 	17.8M  	0:10.57	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8 c2c3
 29	+0.88 	16.6M  	0:09.78	a1b2 a7b8 b2c3 b8b7 c3d2 b7c8 d2d3
 28	+0.88 	7.79M  	0:04.51	a1b2 a7b8 b2c3 b8b7 c3d2 b7c8 d2c2 c8b8 c2d2
 27	+0.88 	3.83M  	0:02.28	a1b2 a7b8 b2c3 b8b7 c3d2 b7c8 d2c2 c8b8 c2d2
 26	+0.91 	3.17M  	0:01.89	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8 c2d2 b8c8 d2c3 c8b7 c3c4 b7b6 c4c3
 25	+0.91 	828360	0:00.48	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8 c2d2 b8c8 d2c3 c8b7
 24	+0.89 	690580	0:00.40	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8 c2c3
 23	+0.89 	349710	0:00.21	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8 c2c3
 22	+0.91 	332440	0:00.20	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8 c2c3 b8b7 c3d2 b7c8
 21	+0.91 	271522	0:00.17	a1b2 a7a8 b2b3 a8a7 b3c2 a7b8
 20	+0.85 	168754	0:00.11	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3c4 b7b6 c4c3 b6c7 c3d2 c7d7 d2e3 d7d8 e3e2 d8c7 e2f2 c7d7 f2f3 d7e7
 19	+0.86 	114033	0:00.06	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3c4
 18	+0.85 	82100  	0:00.04	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3c4 b7b6 c4c3 b6c7 c3d2 c7d7 d2e3 d7c7
 17	+0.86 	52237  	0:00.03	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3c4
 16	+0.85 	39068  	0:00.01	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3e3 b7c7 e3e2 c7d7 e2d3
 15	+0.86 	24545  	0:00.01	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3c3 b7c7 c3c4 c7b6 c4b3 b6c7 b3c3
 14	+0.86 	17674  	0:00.00	a1b2 a7b6 b2c2 b6c7 c2d3 c7b7 d3c3 b7c7 c3c4
 13	+0.86 	11276  	0:00.00	a1b2 a7b6 b2c2 b6c7 c2c3 c7b7 c3d2 b7c8 d2d3 c8c7 d3e3 c7d7 e3f3
 12	+0.86 	7226    	0:00.00	a1b2 a7b6 b2c2 b6c7 c2c3 c7b7 c3c4 b7b6 c4d3 b6c7 d3e3 c7d7
 11	+0.86 	4861    	0:00.00	a1b2 a7b6 b2c2 b6c7 c2c3 c7b7 c3d3 b7c7 d3c4
 10	+0.86 	3296    	0:00.00	a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4
  9	+0.86 	2300    	0:00.00	a1b2 a7b6 b2c3 b6c7 c3c4 c7b6 c4d3 b6c7 d3e3
  8	+0.85 	1595    	0:00.00	a1b2 a7b6 b2c3 b6c7 c3c4 c7b6 c4d3 b6c7
  7	+0.85 	936      	0:00.00	a1b2 a7b6 b2c3 b6c7 c3d3 c7d7 d3e3
  6	+0.84 	631      	0:00.00	a1b2 a7b6 b2c3 b6c7 c3d3 c7d7
  5	+0.86 	422      	0:00.00	a1b2 a7b6 b2c3 b6c7 c3d3
  4	+0.84 	274      	0:00.00	a1b2 a7b6 b2c3 b6c7
  3	+0.85 	64        	0:00.00	a1b2 a7b6 b2c3
  2	+0.76 	17        	0:00.00	a1b2 a7b6
  1	+0.87 	9          	0:00.00	a1b2

It finds the path to a win at 30 ply by grafting, but then loses it again until 35 ply.

[Joost Buijs]

This is what it looks like with an experimental version of my engine.
Conditions are: single core, evaluation: material and PSQT only, move ordering: hash move first and history, TT size: 1024MB.

Code: Select all

position fine70
go infinite
info depth 1 score cp 139 time 0 nodes 3 nps 77914 tbhits 0 pv a1b2
info depth 2 score cp 91 time 0 nodes 9 nps 32975 tbhits 0 pv a1b2 a7b6
info depth 3 score cp 128 time 1 nodes 31 nps 54707 tbhits 0 pv a1b2 a7b6 b2c3
info depth 4 score cp 126 time 1 nodes 91 nps 102363 tbhits 0 pv a1b2 a7b6 b2c3 b6c7
info depth 5 score cp 127 time 1 nodes 201 nps 154624 tbhits 0 pv a1b2 a7b6 b2c3 b6c7 c3c4
info depth 6 score cp 129 time 2 nodes 655 nps 321022 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6
info depth 7 score cp 127 time 2 nodes 983 nps 396602 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c2
info depth 8 score cp 127 time 3 nodes 1274 nps 436126 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4 b6c7
info depth 9 score cp 127 time 3 nodes 1791 nps 515363 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3b3 b6c7 b3c3
info depth 10 score cp 127 time 4 nodes 2413 nps 565444 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3b3 b6c7 b3c3 c7b6
info depth 11 score cp 127 time 5 nodes 3224 nps 629020 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3b3 b6c7 b3c3 c7b6 c3b3
info depth 12 score cp 127 time 6 nodes 3975 nps 685897 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4 b6a6 c4d3 a6b6
info depth 13 score cp 127 time 6 nodes 4624 nps 720030 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4 b6a6 c4d3 a6b6
info depth 14 score cp 127 time 7 nodes 5346 nps 754330 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4 b6a6 c4d3 a6b6
info depth 15 score cp 127 time 8 nodes 6175 nps 796512 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4 b6a6 c4d3 a6b6
info depth 16 score cp 127 time 12 nodes 7487 nps 648009 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3c4 b6a6 c4d3 a6b6
info depth 17 score cp 127 time 13 nodes 10683 nps 850299 tbhits 0 pv a1b2 a7b6 b2c2 b6c7 c2c3 c7b6 c3b3 b6c7 b3c3 c7b6 c3b3 b6c7 b3c3 c7b6 c3b3 b6c7 b3c3
info depth 18 score cp 127 time 15 nodes 20254 nps 1356976 tbhits 0 pv a1b2 a7b6 b2c2 b6b7 c2d3 b7c7 d3c3 c7b6 c3b3 b6c7 b3c3 c7b6 c3b3 b6c7 b3c3 c7b6 c3b3 b6c7
info depth 19 score cp 131 time 20 nodes 57255 nps 2832280 tbhits 0 pv a1b2 a7a8 b2c2 a8b8 c2c3 b8b7
info depth 20 score cp 129 time 38 nodes 216104 nps 5649185 tbhits 0 pv a1b2 a7a8 b2c2 a8b8 c2c3 b8b7
info depth 21 score cp 129 time 40 nodes 222240 nps 5586700 tbhits 0 pv a1b2 a7a8 b2c2 a8b8 c2c3 b8b7
info depth 22 score cp 129 time 41 nodes 230952 nps 5595488 tbhits 0 pv a1b2 a7a8 b2c2 a8b8 c2c3 b8b7
info depth 23 score cp 129 time 44 nodes 243267 nps 5590190 tbhits 0 pv a1b2 a7a8 b2c2 a8b8 c2c3 b8b7
info depth 24 score cp 129 time 51 nodes 300634 nps 5943053 tbhits 0 pv a1b2 a7a8 b2c2 a8b8 c2c3 b8b7
info depth 24 score cp 194 time 15672 nodes 178389776 nps 11382761 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7e7 c2b3 e7f6 b3c4 f6g6 c4b5 g6h5 b5c6 h5g4 c6d6 g4f4 d6c5 f4g5 c5b5 g5f4 b5a5 f4e4
info depth 25 score cp 154 time 17532 nodes 196942372 nps 11233336 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7e7 c2b3 e7f6 b3c4 f6g6 c4b5 g6h5 b5c6 h5g4 c6d6 g4f4 d6c5 f4g5 d5d6 g5f6 d6d7 f6e7 c5c6
info depth 26 score cp 269 time 47017 nodes 519629007 nps 11051898 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7b7 f2g3 b7c7 g3h4 c7d8 h4g5 d8e7 g5f5 e7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7e8 g5g4
info depth 27 score cp 269 time 47035 nodes 519772651 nps 11050776 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7b7 f2g3 b7c7 g3h4 c7d8 h4g5 d8e7 g5f5 e7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7e8 g5g6 e8d8 f6f7
info depth 28 score cp 268 time 47753 nodes 526596839 nps 11027572 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7b7 f2g3 b7c7 g3h4 c7d8 h4g5 d8e7 g5f5 e7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7e8 g5f5 e8d8 f6f7 d8e7
info depth 29 score cp 266 time 49659 nodes 546165067 nps 10998203 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7d8 f2g3 d8e7 g3h4 e7f7 h4h5 f7f6 h5h6 f6f7 h6g5 f7g7 g5f5
info depth 30 score cp 266 time 50210 nodes 551817727 nps 10990144 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7d8 f2g3 d8e7 g3h4 e7f7 h4h5 f7f6 h5h6 f6f7 h6g5 f7g7 g5f5
info depth 31 score cp 266 time 53472 nodes 586506518 nps 10968434 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7d8 f2g3 d8e7 g3h4 e7f7 h4h5 f7f6 h5h6 f6f7 h6g5 f7g7 g5f5
info depth 32 score cp 267 time 701117 nodes 7115263670 nps 10148475 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7d8 f2g3 d8e7 g3h4 e7f7 h4h5 f7f6 h5h6 f6f7 h6g5 f7g7 g5f5
info depth 33 score cp 267 time 712680 nodes 7231460510 nps 10146856 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7d8 f2g3 d8e7 g3h4 e7f7 h4h5 f7f6 h5h6 f6f7 h6g5 f7g7 g5f5
info depth 34 score cp 267 time 747381 nodes 7566764055 nps 10124374 tbhits 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7b7 d1e2 b7c7 e2f2 c7d8 f2g3 d8e7 g3h4 e7f7 h4h5 f7f6 h5h6 f6f7 h6g5 f7g7 g5f5

It goes to depth 24 almost instantly (51 msec.), after this promotions appear on the board and it slows down, it also finds the correct move on depth 24. The evaluation function has no knowledge about passed pawns at all, when I add this it will probably find the correct move earlier on.

[Ronald]

I tried to understand why your engine is not working as expected, so i tried to turn of as much as possible in my engine. What is left then is a staged movegenerator (hash, captures, quiets including promotions) which i cannot turn off, with a hashtable. No move ordering MVV/see/killer/history etc,and only a "clean" alfabeta and my engine only has PSQT for evaluation, then it will still find the correct move very fast.

It only has a problem with finding the solution if it doesn't use the hashmove. I'm not saying that is your problem, but you might check if you have hashmoves and if so that they are executed as the first move in the position, because other mover ordering and alfabeta tricks seem to have a lot less influence on this position.

Here is the output of the clean version of my engine.

Code: Select all

info score cp 131 depth 11 seldepth 10 nodes 5936 time 0 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 
info score cp 131 depth 12 seldepth 11 nodes 7150 time 0 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 
info score cp 131 depth 13 seldepth 13 nodes 10769 time 1 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 
info score cp 131 depth 14 seldepth 15 nodes 15048 time 1 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 c2c1 
info score cp 131 depth 15 seldepth 17 nodes 20854 time 2 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 c2c1 
info score cp 131 depth 16 seldepth 17 nodes 25393 time 3 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 c2c1 
info score cp 131 depth 17 seldepth 19 nodes 32369 time 3 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 
info score cp 131 depth 18 seldepth 20 nodes 35990 time 4 hashfull 0 pv a1b2 a7b6 b2b3 b6a7 b3c2 a7a6 
info score cp 142 depth 19 seldepth 21 nodes 44342 time 5 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7e7 c2b3 e7f6 b3c4 f6g6 c4b5 g6h5 b5a5 h5g4 a5b6 g4f4 b6c7 
info score cp 136 depth 20 seldepth 21 nodes 47905 time 5 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1b2 c7c8 b2c3 c8b7 
info score cp 186 depth 21 seldepth 21 nodes 51396 time 5 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7e7 c2b3 e7f6 b3c4 f6g6 c4b5 g6h5 b5c6 h5g4 c6d6 g4f4 d6e6 f4e3 d5d6 
info score cp 185 depth 22 seldepth 23 nodes 57192 time 6 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7e7 c2b3 e7f6 b3c4 f6g6 c4b5 g6h5 b5c6 h5g4 c6d6 g4f4 d6e6 f4e3 d5d6 f5f4 
info score cp 239 depth 23 seldepth 24 nodes 70206 time 7 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 239 depth 24 seldepth 26 nodes 78696 time 8 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 249 depth 25 seldepth 28 nodes 90672 time 10 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 254 depth 26 seldepth 29 nodes 105880 time 12 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 254 depth 27 seldepth 30 nodes 122557 time 13 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 249 depth 28 seldepth 32 nodes 154923 time 17 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 c2d3 c7b7 d3e3 b7c7 e3f2 c7d7 f2g3 d7e7 g3h4 e7f6 h4h5 f6f7 h5g5 f7g7 g5f5 g7f7 f5g5 f7e7 g5f5 e7f7 
info score cp 314 depth 29 seldepth 35 nodes 197687 time 23 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 314 depth 30 seldepth 36 nodes 246744 time 29 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 324 depth 31 seldepth 37 nodes 327415 time 42 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 339 depth 32 seldepth 39 nodes 491738 time 68 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 324 depth 33 seldepth 41 nodes 766361 time 115 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 319 depth 34 seldepth 43 nodes 1402509 time 228 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 334 depth 35 seldepth 44 nodes 3026360 time 517 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 
info score cp 334 depth 36 seldepth 46 nodes 7062977 time 1239 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 c2d3 c7b7 d3e2 b7c7 e2f2 c7d7 f2g3 d7e7 g3h4 e7f6 h4h5 f6f7 h5g5 f7g7 g5f5 g7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7f8 g5f4 f8g8 f4g4 g8h7 g4g5 h7g8 
info score cp 354 depth 37 seldepth 48 nodes 16932146 time 3066 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 c2d3 c7b7 d3e2 b7c7 e2f2 c7d7 f2g3 d7e7 g3h4 e7f6 h4h5 f6f7 h5g5 f7g7 g5f5 g7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7f8 g5f4 f8g8 f4g4 g8h7 g4f5 h7g8 f5e6 
info score cp 354 depth 38 seldepth 50 nodes 61587447 time 11502 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 c2d3 c7b7 d3e2 b7c7 e2f2 c7d7 f2g3 d7e7 g3h4 e7f6 h4h5 f6f7 h5g5 f7g7 g5f5 g7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7f8 g5f4 f8g8 f4g4 g8f8 g4g5 f8g8 
info score cp 354 depth 39 seldepth 52 nodes 92761648 time 17410 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 c2d3 c7b7 d3e2 b7c7 e2f2 c7d7 f2g3 d7e7 g3h4 e7f6 h4h5 f6f7 h5g5 f7g7 g5f5 g7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7f8 g5f4 f8g8 f4g4 g8f8 g4g5 
info score cp 354 depth 40 seldepth 53 nodes 178684884 time 34005 hashfull 0 pv a1b1 a7b7 b1c1 b7c7 c1d1 c7d7 d1c2 d7c7 c2d3 c7b7 d3e2 b7c7 e2f2 c7d7 f2g3 d7e7 g3h4 e7f6 h4h5 f6f7 h5g5 f7g7 g5f5 g7f7 f5g5 f7g7 f4f5 g7f7 f5f6 f7f8 g5f4 f8g8 f4g4 g8f8 g4g5 
bestmove a1b1 ponder a7b7