I'm not sure if it's still an issue since I don't use Rust daily; but one recommendation I'd make concerning array bounds checking is to do something like electric-fence and allow the compiler to be told to allocate arrays to end at the page boundary such that the hardware interrupts when you go off the edge.
If the compiler restricts such an array to only being indexed with an unsigned integer, then it can be safe but forego bounds checking altogether since the lower bound is always 0 and the upper bound check is hardware accelerated.
Yeah, a lot of those would be faster now, because SIMD was stabilized. That's the source of the discrepancy on n-body, for example. I don't think anyone has bothered to really submit new implementations.
Most bounds checks can be hoisted out of the compiler can’t figure it out on its own via asserts. In general it’s not a huge problem in real-world code.
You made that claim before, and I showed you the Rust n-body program "vector instructions using SIMD" contributed 5 months ago.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Edit: the correct URL is https://benchmarksgame-team.pages.debian.net/benchmarksgame/....
It shows 0.48 seconds, and 2 seconds, but https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows 13.27. Why isn't that one on the main page?
HN have now corrected the URL, as I asked.
> It shows 0.48 seconds, and 2 seconds
It shows 3 different workloads:
secs N
0.48 500,000
2.01 5,000,000
20.09 50,000,000
Which we can see is the time for `n-body #2` at the largest workload:
secs N
0.54 500,000
1.33 5,000,000
13.27 50,000,000
I don't know which you consider to be the "main page".
We can see that measurements for `n-body #2` are shown on both:
faster/rust.html
measurements/rust.html