Timing comparision for matches between fast-chess and cutechess-cli #595
Replies: 4 comments 2 replies
-
looks good i think, a bit faster in realtime, and fc with higher user time because it uses multiple threads for the user code |
Beta Was this translation helpful? Give feedback.
-
yes, looks certainly good. I did do a
I guess some overhead in |
Beta Was this translation helpful? Give feedback.
-
when compiled with the testing flags: I have
|
Beta Was this translation helpful? Give feedback.
-
I attach a memory profiling for a match as obtained with: This leads to:
Even though massif groups things by bytes allocated an not the number of allocations, this might be useful, and I wonder if a few pre-allocated vectors / string could essentially remove all these allocates from the profile. |
Beta Was this translation helpful? Give feedback.
-
Testing performance with the following script on 16c/32t hardware
i.e. fixed depth fast games, full load
games finish 1.56x faster with fc compared to cutechess
if I analyze the pgn for the average time per move, fast-chess accounts for 0.00442054s while cutechess accounts for 0.0112434s
This is interesting, since we play node-accurate identical games.
Increasing the depth to 10 and 8:
so about 1.3x faster with fc.
times per move:
0.0135797
0.0198652
so again about 6-7ms more overhead accounted for by cc.
At TC of 2+0.02s we have:
In this match, we see no time losses for fc, but cc has
i.e. 10% time loss.
Average time is
0.0455537 fc
0.0486419 cc
Total number of plies played:
125096 fc
128741 cc
The draw rates are similar (40.5% vs 41%).
Beta Was this translation helpful? Give feedback.
All reactions