2 ms·
You’re overstating things. First, 100k objects is for very complicated games. And even then that’s 10us per object. “Nanoseconds” is the wrong order of magnitud
by vlovich123 3y ago
You’re overstating things. First, 100k objects is for very complicated games. And even then that’s 10us per object. “Nanoseconds” is the wrong order of magnitude - it’s closer to 10s or 100s of ns and a bounds check is cheaper than that typically and amortized across all objects. Bounds checks are unlikely going to show up unless you do a bounds check for each element. And most of the time it won’t be there with idiomatic rust and you’ll need to sprinkle unsafe in a handful of hotspots at most for perf reasons. Also most games made don’t have the same requirements. I agree the ecosystem isn’t there yet. But also, gaming is the least important industry because safety there is an after thought.
As for finance, you’re hyper focusing on HFT which is only part of what they use c++ for.
And again, I think you’re being a bit overly dramatic about the overhead Rust imposes or how much “unsafe” is require to recapture the performance.
As for aliasing, you’ve got it backwards. C++ loose aliasing rules means that it can’t enable optimizations that generate better code. Rust’s stricter aliasing rules means they ask llvm to compile with strict aliasing which generates much better code because the compiler can make assumptions that aren’t possible in c++ unless you explicitly force it to (and in those cases safety can be impacted so in practice no one enabled strict-alias in a c++ codebase which we know because llvm has bugs in that code path all over the place that Rust hit and had to fix which it is).
- adastra22 3y agoRust emits memory barriers that C++ won't. That can result in unnecessary* execution delays in these tight loops, that yes costs a nanosecond or so. In cases where there's no conflict the memory barrier just occupies one cycle of the instruction decoder, but it can cause the CPU to not be able to reorder instructions in the most efficient way. This will cost you an instruction or two. On a ~2GHz cpu, that's 0.5 ns. *Unnecessary because the thing being done won't crash the game if it is accidentally interleaved with a different update or whatever, and this is exceedingly unlikely to happen in a repeatable way. At worst you'll get a visual glitch gamers are used to, but often it's something internal and non-visible anyway.
- heinrich5991 3y agoCan you give an example of a memory barrier that Rust emits that C++ won't? :) This is the first time I hear about this.
- adastra22 3y agoC/C++ doesn't emit them at all unless you ask it to. At least on x86-like architectures. It might have to on ARM because of its weak memory model? I'm not sure about that. But the C++ standard does basically zilch with respect to thread safety unless you use the appropriate memory fence compiler directives.
- estebank 3y agoWhat memory fences does the Rust compiler emit without you asking?
- adastra22 3y agoThe Rust compiler won’t compile code that mutates shared state unless there are appropriate memory fences. It makes you insert these barriers for correctness.
- heinrich5991 3y agoCan you give an example? I think relaxed atomics don't have memory fences.