TalkChess.com

Hello,

I made a small investigation in orden to fast my makemove and unmakemoves routines. In my engine, this routines have switch statements that examines the moved pieced and the captured pieces if it exits. My statements are sorted following standard enumeration: no_piece, pawn, knight, bishop, root, queen and king.

What I did is examine four thousand chess games (that I think should be enough) counting how many times a piece is moved, so I can use that information to change the orden in which the switch statement examines pieces.

This where may findings:
So I changed my routines to the above order. As you can see I had not to change captures order, as it is the usual, only I changed the moved piece. It is curious that rooks is the more often moved piece, even over pawns.

For my surprise, my engines scored 15 Elo points worse for that little change. This makes me things that maybe is not the same the moves stadistics doing in a game, than stadistics doing in the search over all games. Any opinions here?

I post this findings for it somebody find they usefull.

Regards
Fermin

Your measurements are for how many times a piece moved , not how good it turned out to be. Indeed it should perform worse if you put the rook before the pawns. Consider SEE or MVV/LVA order than overall movement statistics. The pawns easily refute many silly moves that one can make. Your statistics are more appropriate for mobility changes.

Also if you want to optimize things like order of switch by playing games, use profile guided optimization. Play as many games as you want and it should be able to pick up that and much more from the statistics it collects.

Hi Fermin

Tell me if I've understood properly your idea: in order to make you moves generator faster, you want to put first in the switch the pieces that are moved more often, because that way you have to check less conditions.

If that's the idea, then I guess you shouldn't take statistics from played games, but from moves generated by the moves generator itself. I mean: generate all the moves to, for example, ply 8. Count how many of the generated moves were made by each type of piece, and then use this info to order the cases of the switch of your move generator.


Cheers

E Diaz

Hi Fermín,

If you are only touching make and unmake, you probably won't be changing functional equivalence, so you don't need to play games, just check the speed before and after the change.

If you define the pieces as consecutive ints starting at 0 (or with and enum), the compiler will probably create a jump table to make it constant time, so the order of the switch cases won't matter and you will get the same speed as before.

Regards

changing the order of the switch should not result in a speedup anyways, since the switch should be compiled as a jump table instead of a chain of if statements since it uses (presumably) contiguous values (0, 1, 2, 3, 4, 5, 6) - perhaps changing the order from that resulted in it compiling as not a jump table but i'd assume the compiler should rearrange them unless some of your case statements are not seperated by a break;

Kempelen wrote: For my surprise, my engines scored 15 Elo points worse for that little change.

How did you measure this? What is the error bar?

Evert wrote:

Kempelen wrote: For my surprise, my engines scored 15 Elo points worse for that little change.

How did you measure this? What is the error bar?

Comparing result of 4.000 games before change and 4000 games after the change, +- 10 elo error bar.