I am a little dissapointed in the move ordering of my chess engine. I have:
PV move from last iteration of iterative deepening.
Hash move inside the search tree.
Internal iterative deepening.
Mvv/Lva for captures
Killer moves
History heuristic
Countermove history
All inside a PVS-negamax framework. The way i measure it is by incrementing a counter each time there is a fail high, and another one each time the fail high happens at the first move searched, and then divide the "fail high first count" with "fail high count". From this, i calculate an overall move ordering of ~0.85 or 85%, but I would like/expect it to reach >90%.
Is the relatively low number just because I need to add more move ordering heuristics or would you expect it to be because of a bug in the code?
85% is not too bad, no need to be disappointed only by that number ... 80-90% is common but the "fail high on first move" percentage alone does not tell enough about your overall search performance. Effective branching factor, and in the end "time to depth" tell you more, in my opinion.
Sven Schüle (engine author: Jumbo, KnockOut, Surprise)
Every engine has its own ecosystem of what works best.
For Tinker (FWIW) my order is different:
HashMove
PVMove
InCheck (evasions)
GoodCaptures
Killers (Better to do killers after captures and only store non-captures as killers)
NonCaptures
PoorCaptures
Each move is only tried one time, so for example, the hash move is often the PV move.
Crafty is also very well-documented in this area.
I am a little dissapointed in the move ordering of my chess engine. I have:
PV move from last iteration of iterative deepening.
Hash move inside the search tree.
Internal iterative deepening.
Mvv/Lva for captures
Killer moves
History heuristic
Countermove history
All inside a PVS-negamax framework. The way i measure it is by incrementing a counter each time there is a fail high, and another one each time the fail high happens at the first move searched, and then divide the "fail high first count" with "fail high count". From this, i calculate an overall move ordering of ~0.85 or 85%, but I would like/expect it to reach >90%.
Is the relatively low number just because I need to add more move ordering heuristics or would you expect it to be because of a bug in the code?
Thanks for your help in advance
Created a tool called move ordering spy to measure the effect of move ordering changes by testing it with specialized epd test suite, at fixed depth search and measure the score based from the points in every test position, also measures the time. The engine version with changes to move ordering that gets a higher score and shorter time could be the best. The first priority to look up is the points it gets from the test suite. Of course you need to verify the perf by playing games.
