hgm wrote:I can add that I have seen cases where deleting unreachable code caused a slowdown of nearly 15% (in qperft). The assembly for the reachable code looked identical in both cases. I don't know if modern CPUs still can exhibit such a paradoxical behavior.
This is interesting, I recently experienced something similar I can't explain (yet the code is different):
Remove one byte and a million things will change in the way the various caches interact, and some of these interactions can make a big difference. It does not have to be the code you changed that becomes faster or slower; the slowdown could happen in an entirely unrelated part of the program.
So in the end you just need to rely on your own judgement. If there is no sound explanation for a speedup or slowdown at the level that you can influence (i.e. at the C/C++ level), then just ignore it.
cdani wrote:The test are with a little more of 710,000 fen positions of any phase of the game, generating the moves 100 times for each position.
But then you do not properly test the impact of your unrolled code on the cpu cache and branch prediction buffer. A faster perft does not necessarily mean a faster search, here.
In fact, by repeating the move generation 100 times for each position, you are also "cheating" the branch prediction logic. So it is not even clear that your perft speeds up here.
cdani wrote:The test are with a little more of 710,000 fen positions of any phase of the game, generating the moves 100 times for each position.
But then you do not properly test the impact of your unrolled code on the cpu cache and branch prediction buffer. A faster perft does not necessarily mean a faster search, here.
In fact, by repeating the move generation 100 times for each position, you are also "cheating" the branch prediction logic. So it is not even clear that your perft speeds up here.
Sure. But I generate the moves not 100 times for the same position, but one time for each 710000 positions, and then again, and then again, 100 times.
Playing games should be impossible to see any meaningful win.
I suppose I will try to retest doing a search to some depth, to obtain something better.
cdani wrote:The test are with a little more of 710,000 fen positions of any phase of the game, generating the moves 100 times for each position.
But then you do not properly test the impact of your unrolled code on the cpu cache and branch prediction buffer. A faster perft does not necessarily mean a faster search, here.
In fact, by repeating the move generation 100 times for each position, you are also "cheating" the branch prediction logic. So it is not even clear that your perft speeds up here.
Sure. But I generate the moves not 100 times for the same position, but one time for each 710000 positions, and then again, and then again, 100 times.
Playing games should be impossible to see any meaningful win.
I suppose I will try to retest doing a search to some depth, to obtain something better.
The last sentence is what I would have proposed as well: measure search speed. Maybe searching to a very low depth (4?) with 10000 positions could already be sufficient so that the measurement does not take too long.
Sven Schüle wrote:The last sentence is what I would have proposed as well: measure search speed. Maybe searching to a very low depth (4?) with 10000 positions could already be sufficient so that the measurement does not take too long.
I would reduce the number of positions and increase the depth. (As long as the test positions are reasonably representative of the various stages of the game, I don't see why more would be necessary to test speed.)
To get reliable timings on Linux, first use the cpupower command to set the cpufreq governor to performance (instead of powersave). And make sure firefox is not running (e.g. by suspending it).
cdani wrote:
So there is no doubt that the fastest one is the first. I thought than the 4th could be the fastest but was not the case. Maybe is Visual studio that is not optimizing very well.
