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
You can pick languages other than C++ or Java, but for a specialized and bespoke hardware/software combination like HFT, you'll be at a disadvantage vs other teams.
In my experience, or at least something I've seen at 3 different firms now, there's also an issue around the kind of people that pick exotic languages in terms of pragmatism. Often times the Scala/Haskell/whatever else side of the codebase is beautiful and slow moving while the hacky C++ side actually works and is agile.
Compared to the typical functional language applications, Rust is different in that it's mainly being battle tested in the kind of Firefox performance issues that are very interesting to an HFT programmer and Rust easily interfaces with C.