If Rust wasn't able to elide bounds checks, that is most likely where the perf difference is from. Analyzing the output the assembly output from goldbolt or looking at the MIR can help.

https://stefan-marr.de/2022/10/cost-of-safety-in-java/

Unsafety buys you a little more performance, but the baseline should the safe version, not the unsafe version. It is like having to explain on a case by case basis why you aren't using lead pipes for this application.

Always default to safety. The difference between safe and unsafe native code is usually single digit percentage points. Or weeks on a Moore scale.

I think you replied to the wrong comment, mine was about zig vs C++.

I am talking about the whole stack of benchmarks and why there is a spread in perf. I am replying to you and the top level comment, if only the convos were a graph and not a tree.

This should also be the case for nim. Generated C always looks very simple with -d:danger (when all memory access checks disappear).

If I do nimble build -d:lto -d:danger --passC:-march=native I get 1920 fps while if I do nimble build -d:lto -d:release --passC:-march=native I still get 1775 fps. So, at least for Nim, the checks are only a 1.08x slowdown..Not so bad compared to the 2521 vs 1626 = 1.55x Zig-Rust slowdown on the author's machine.

Heck, I see 1.33x differences in run times between the first & second run of the rust branch of his benchmark, but only 1.05x diffs in run times between 1st & 2nd Nim branch.

In my experience, reasoning about things like this is rarely as simple as "bounds checks" which are (often) the most highly predictable branches.

True. Recently I noticed that std/sha1 takes 8x the time on M1 release vs danger. Yet on amd64 it's only a <10% difference.