5 ms·
At least for Rust, the raw compiled code performance isn't quite there yet. You can pick languages other than C++ or Java, but for a specialized and bespoke ha
by CoolGuySteve 8y ago
At least for Rust, the raw compiled code performance isn't quite there yet.
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.
- steveklabnik 8y agoWhat kinds of performance issues are you running into? We’d love bug reports!
- CoolGuySteve 8y agoNo real world issues yet. Every couple years I look up some Rust performance benchmarks and pass on it. Benchmarks like this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... 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.
- steveklabnik 8y agoThanks for elaborating! 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.
- igouy 8y ago> That's the source of the discrepancy on n-body… 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/measurements/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Edit: the correct URL is https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-5.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/....
- steveklabnik 8y agoWhich one of those is the right one? Number 5? It shows 0.48 seconds, and 2 seconds, but https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows 13.27. Why isn't that one on the main page?
- igouy 8y ago> Which one of those is the right one? Number 5? 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 > … but … shows 13.27… 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 > Why isn't that one on the main page? 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 and measurements/rust.html
- steveklabnik 8y agoOkay, I see now. It's about the three different measurements. Thank you!