3 ms·

> Rust isn’t a fit for those use cases. Not without a mountain of work that no one is doing, nor would be likely to be accepted as it conflicts with the design

> Rust isn’t a fit for those use cases. Not without a mountain of work that no one is doing, nor would be likely to be accepted as it conflicts with the design goals of Rust. Could you elaborate?

adastra22 3y ago
Rust's safety features and assurances get in the way of absolutely minimal latency requirements. It'd end up as a heaping layer of `unsafe{}` blocks, which would defeat the point, and I'm not even sure that would be sufficient. C++ lets you make a lot of unsafe assumptions about aliasing and such, which an optimizing compiler turns into extremely fast code but is in general unsafe. I'm not sure the Rust compiler would be able to output such code as it currently stands. Rust's approach is to produce code that is as fast as possible, but with the assumption that safety is paramount over breaking speed records. That's opposite the tradeoff that cutting edge games want to make. Keep in mind a game engine might make updates to 100,000 objects, 144 times per second. In that context, every nanosecond really does matter. Investment banks / high frequency traders care a little bit more about safety guarantees. But not as much as you might think. A segfault can cost you a trade, but being 0.5ns slower than the competition will cost you your business.
- 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 ago
    Rust 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 ago
      Can 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 ago
        C/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 ago
        What memory fences does the Rust compiler emit without you asking?
        adastra22 3y ago
        The Rust compiler won’t compile code that mutates shared state unless there are appropriate memory fences. It makes you insert these barriers for correctness.

> Rust isn’t a fit for those use cases. Not without a mountain of work that no one is doing, nor would be likely to be accepted as it conflicts with the design goals of Rust. Could you elaborate?

adastra22 3y ago

Rust's safety features and assurances get in the way of absolutely minimal latency requirements. It'd end up as a heaping layer of `unsafe{}` blocks, which would defeat the point, and I'm not even sure that would be sufficient. C++ lets you make a lot of unsafe assumptions about aliasing and such, which an optimizing compiler turns into extremely fast code but is in general unsafe. I'm not sure the Rust compiler would be able to output such code as it currently stands. Rust's approach is to produce code that is as fast as possible, but with the assumption that safety is paramount over breaking speed records. That's opposite the tradeoff that cutting edge games want to make. Keep in mind a game engine might make updates to 100,000 objects, 144 times per second. In that context, every nanosecond really does matter. Investment banks / high frequency traders care a little bit more about safety guarantees. But not as much as you might think. A segfault can cost you a trade, but being 0.5ns slower than the competition will cost you your business.

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 ago
  Rust 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 ago
    Can 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 ago
      C/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 ago
        What memory fences does the Rust compiler emit without you asking?
        adastra22 3y ago
        The Rust compiler won’t compile code that mutates shared state unless there are appropriate memory fences. It makes you insert these barriers for correctness.