A while ago, a thread ran here about the costs of copy-make vs make/undo. As Don Dailey pointed out, copy-make makes the search interface simpler, especially in a parallel context and that you save the undo logic. The price you pay is copying around something like 192 bytes (3 chache lines!) every time you make a move. Compared to chess, the games of draughts and checkers need a lot less data to keep track of a position. Instead of bitboards for 6 types of pieces times 2 colors, one needs only 3 bitboards (24 bytes). This makes it even more attractive to use copy-make. For my draughts engine, copy-make was almost exactly a break-even transition from make/undo.
I ran a small experiment with my draughts engine. All in all my current position struct is 64 bytes, including the piece bitboards, 50ply counter, a hash key, and a pointer to the previous position. I created 7 test versions where I padded the struct to have 128, 192, 256, 512, 1024, 2048 and 4096 bytes, respectively. For each version, I ran a 15-ply search (29 seconds) on the initial position. Below are the timings and the percentage change with respect to the baseline version.
Code: Select all
state time change
64 28672
128 28828 0,5%
192 29281 2,1%
256 30688 7,0%
512 31875 11,2%
1024 33188 15,8%
2048 36547 27,5%
4096 38531 34,4%
Depending on whether one can emulate Don Dailey's 192 bytes or squeeze the entire state into 256 bytes, one would probably get a performance hit between 2 and 7 percent. But remember that my baseline version already has copy-make, so the above table is the pure "copy penalty". For me the padded versions don't receive the "undo bonus" that one would get if one were to try this for a make/undo engine such as Crafty/Fruit or Stockfish. E.g., the current Stateinfo struct in Stockfish (that is copied every move) is already about 72 bytes if I remember, so the impact of a full copy-make would likely be similar to the table above.
Conclusion: it seems copy-make can be made competitive compared to the usual make-undo. Plus of course the simplification of the whole split point business for multicore engines.
