performance of copy-make

[Joost Buijs]

I've been experimenting with this in the past quite a lot and I always found copy-make performing much worse as make/unmake.

In my engine I have to copy:
piece bitboards 96 bytes
occupied bitboard 8 bytes
piece array 64 bytes
king locations 2 bytes
hash 8 bytes
pawn hash 8 bytes
incremental evaluation for both colors 4 bytes
incremental stage for both colors 4 bytes
50 move counter 1 byte

So this is atleast 195 bytes and there even is some additional stuff like
castle status enpassant status etc.

Actually I don't use the 8 bit or 16 bit fields I mentioned above but I like to make most fields 64 bit because using 8 or 16 bit values in a packed struct gives a performance hit as well because it is likely that they are not properly aligned.

[Joost Buijs]

For the split operation copying doesn't hurt that much because it usually takes place 3 or 4 ply below the leaves of the tree.

[Rein Halbersma]

Thanks for sharing this info. So you could comfortably fit the whole position within 256 bytes, while making sure of the various alignment issues? Did you record how much of a performance hit it gave? 50%? factor of 2?

[Joost Buijs]

Yes the whole position fits comfortably within 256 bytes, no problem.
I don't have the exact numbers anymore for the copy-make because I abandoned it a long time ago.

The performance of my current engine with perft (move generation/make/unmake, no bulk counting ) with full incremental update of the static evaluation and hashkeys etc. is around 25 mln moves per second on a single core i7. I hope you can do something with these numbers.

[Joost Buijs]

Maybe the performance issue of copy-make is not that important at all because 90% of the time is spent in the evaluation function. I assume you will hardly notice the performance penalty of copy-make on the program as a whole.

[Rein Halbersma]

My table in the top post of this thread was the time to depth for a full 15-ply search on the initial position in international draughts, not for a stripped down perft run! All versions with padding compare the extra time for this full search. So 7% extra time for the 256 struct compared to the 64 byte struct.

[rbarreira]

Maybe the performance issue of copy-make is not that important at all because 90% of the time is spent in the evaluation function. I assume you will hardly notice the performance penalty of copy-make on the program as a whole.

Even if 90% of the time is spent in the evaluation function, that doesn't mean copy-make can't have a very negative impact. For example, if it fills up the cache with garbage it will make the evaluation run slower.

Profiling code is very useful but it does not tell the whole story. It only shows where your program spends its time, not why it spends its time there.

[Rein Halbersma]

Maybe the performance issue of copy-make is not that important at all because 90% of the time is spent in the evaluation function. I assume you will hardly notice the performance penalty of copy-make on the program as a whole.

Even if 90% of the time is spent in the evaluation function, that doesn't mean copy-make can't have a very negative impact. For example, if it fills up the cache with garbage it will make the evaluation run slower.

Profiling code is very useful but it does not tell the whole story. It only shows where your program spends its time, not why it spends its time there.

For a 16 ply search and 256 bytes per position, you are at about 4K per core. That should comfortably fit into cache.

[rbarreira]

Maybe the performance issue of copy-make is not that important at all because 90% of the time is spent in the evaluation function. I assume you will hardly notice the performance penalty of copy-make on the program as a whole.

Even if 90% of the time is spent in the evaluation function, that doesn't mean copy-make can't have a very negative impact. For example, if it fills up the cache with garbage it will make the evaluation run slower.

Profiling code is very useful but it does not tell the whole story. It only shows where your program spends its time, not why it spends its time there.

For a 16 ply search and 256 bytes per position, you are at about 4K per core. That should comfortably fit into cache.

Sure it fits, but it pushes out other things from the cache in order to fit. Especially L1 cache which is quite small. This makes other functions in the program slower, and might not show up in a profiler report.

[Aleks Peshkov]

1) It is possible to perform "read - modify - write_to_the_new_location" operations with some position representation parts without explicit copy stage. Updating Zobrist hash is obvious example.

2) Latency of position copy and other making move work can be hidden during TT hash probe memory prefetch. I doubt it is possible to do anything useful in parallel during undo move operations.