No questions. Just a message.
I got chessnix compiling for 0.16 and it is exactly twice as slow.
Drama… I resign.
Edit: Anyone who can port my code to 0.16 with the same speed will get eternal glory 
What have you been doing to measure performance until now? Do those tool(s) provide any insight as to what is different?
I have a simple benchmark getting many millions of positions and measuring the time that costs.
With 0.15.2 that is:
Total nodes: 18999768562 13.780s 1378.7580 Mnodes/s (1.378.758.004)
With 0.16.0 it takes double the time. (670 Mnodes/s).
Not a real benchmark but enough indication something went terribly wrong (with just a few little changes actually in the source).
It took me ages to get it fast… now I am sad.
Looks like the next step for you is to invest into learning additional performance measurement tools and techniques. Not only will such things potentially shed light on what happened across Zig versions, but likely there are other optimization opportunities to claim, once you find out where those bottlenecks are. These skills will continue to serve you not only for this project but for your entire career.
Here’s a picture I have hanging on the wall in my office to inspire you:
21 Likes
Eric, please. The first rule of nerd sniping asking for help with profiling code is you have to provide a one-liner we can all easily run.
Both
❯ nix run nixpkgs#zig build run
and
❯ nix run nixpkgs#zig_0_15 build run
result in compile errors for me on a freshly cloned ericlangedijk/chessnix repo (because mtg is missing from time.TimeManager.
Can you please provide the hash of the most recent known-to-compile commit, and also the exact command to run to clock the program? Is it just running the main exe and typing bench in the CLI prompt? Or one of the perft/qperftcommands, and if so, with which argument?
4 Likes
That error i solved (hour ago). just forgot one file update. it should compile for 0.15.2.
The last commit is the newest actual version.
And the command in the terminal is “bench”, which executes 4 perfts.
Edit: I don’t know what nerd-sniping is. But I added that line out of total despair
As written: it took me ages to get it fast, by trial and error. And I am noob in many fields. I am not able to look at 1.5 km of assembly and find out what is going on,
Ok ok, thank you, the current version at the time of this comment is 7153bf06 and it indeed compiles with Zig 0.15.2! But also not with any other version:
But that’s ok, because we smort. And can remove the check.
Also, sorry, the term “nerd sniping” is a reference from a webcomic that old people like. It basically means posing a puzzle to people who, when in presence of puzzles, go “Oh, I think I might solve this!”
1 Like
yes, it will not compile with 0.14.x.
0.15.0 i don’t know.
0.16.0 not at all. Because of Io and timer stuff.
No worries!! Just wondering since you mentioned a performance degradation with Zig 0.16 in the OP, is the latest commit on GitHub what you were testing with? Because any additional changes to the code to get it to compile might have had an impact.
I haven’t studied it carefully, but considering that due to an upstream LLVM bug Zig 0.16 had to disable loop vectorization, it is predictable that some performance regressions would occur.
1 Like
No changes! The current situation is the exact situation here at my home.
Ouch ok… My expectations were set on “it will be faster” because of array access. So I will have to skip a zig version or 2