4 ms·

Is there anything specific to Rust that this library does which modern C++ can’t match in performance? I’d be very interested to understand if there is.

slashdev 2y ago
No, there shouldn’t be. Rust is not magic and you can compile both with llvm (clang++). If you specify that the pointers don’t alias, and don’t use any language sugar that adds overhead on either side, the performance will be very similar.
- nicholassm83 2y ago
  I agree. The Rust implementation even needs to use a few unsafe blocks (to work with UnsafeCells internally) but is mostly safe code. Other than that you can achieve the same in C++. But I think the real benefit is that you can write the rest of your code in safe Rust.
  - alchemist1e9 2y ago
    Unless the rest of your code is already in C++ and you’re interested in this new better disrupter implementation, that’s probably a common situation for people interested in this topic. Any recommendations for those in that situation? perhaps existing C++ implementations already match this idk.
  - bluejekyll 2y ago
    While you’re not explicitly saying this, C++ in Rust’s terms, is all unsafe. In a multi-threading context like this, that’s even more important.
    - nicholassm83 2y ago
      I'm trying to be polite. :-) And there is a lot of great C++ code and developers out there - especially in the e-trading/HFT space.
    - zamalek 2y ago
      Nit: C/++ is safer than Rust unsafe. There are constraints (no aliasing) that must be upheld in unsafe.
pornel 2y ago
For Rust users there's a significant difference: * it's a Cargo package, which is trivial to add to a project. Pure-Rust projects are easier to build cross-platform. * It exports a safe Rust interface. It has configurable levels of thread safety, which are protected from misuse at compile time. The point isn't that C++ can match performance, but that you don't have to use C++, and still get the performance, plus other niceties. This is "is there anything specific to C++ that assembly can't match in performance?" one step removed.
- alchemist1e9 2y ago
  I had expected that’s true. You just never know if perhaps Rust compilers have some more advanced/modern tricks that can only be accessed easily by writing in Rust without writing assembly directly.
  - pornel 2y ago
    There is a trick in truly exclusive references (marked noalias in LLVM). C++ doesn't even have the lesser form of C restrict pointers. However, a truly performance focused C or C++ library would tweak the code to get the desired optimizations one way or another. A more nebulous Rust perf thing is ability rely on the compiler to check lifetimes and immutability/exclusivity of pointers. This allows using fine-grained multithreading, even with 3rd party code, without the worry it's going to cause heisenbugs. It allows library APIs to work with temporary complex references that would be footguns otherwise (e.g. prefer string_view instead of string. Don't copy inputs defensively, because it's known they can't be mutated or freed even by a broken caller).
    - CuriousCosmic 2y ago
      > C++ doesn't even have the lesser form of C restrict pointers. Standard C++ doesn't but `noalias` is available in basically every major compiler (including the more niche embedded toolchains).
      - 3836293648 2y ago

slashdev 2y ago

No, there shouldn’t be. Rust is not magic and you can compile both with llvm (clang++). If you specify that the pointers don’t alias, and don’t use any language sugar that adds overhead on either side, the performance will be very similar.

nicholassm83 2y ago
I agree. The Rust implementation even needs to use a few unsafe blocks (to work with UnsafeCells internally) but is mostly safe code. Other than that you can achieve the same in C++. But I think the real benefit is that you can write the rest of your code in safe Rust.
- alchemist1e9 2y ago
  Unless the rest of your code is already in C++ and you’re interested in this new better disrupter implementation, that’s probably a common situation for people interested in this topic. Any recommendations for those in that situation? perhaps existing C++ implementations already match this idk.
- bluejekyll 2y ago
  While you’re not explicitly saying this, C++ in Rust’s terms, is all unsafe. In a multi-threading context like this, that’s even more important.
  - nicholassm83 2y ago
    I'm trying to be polite. :-) And there is a lot of great C++ code and developers out there - especially in the e-trading/HFT space.
  - zamalek 2y ago
    Nit: C/++ is safer than Rust unsafe. There are constraints (no aliasing) that must be upheld in unsafe.

pornel 2y ago

For Rust users there's a significant difference: * it's a Cargo package, which is trivial to add to a project. Pure-Rust projects are easier to build cross-platform. * It exports a safe Rust interface. It has configurable levels of thread safety, which are protected from misuse at compile time. The point isn't that C++ can match performance, but that you don't have to use C++, and still get the performance, plus other niceties. This is "is there anything specific to C++ that assembly can't match in performance?" one step removed.

alchemist1e9 2y ago
I had expected that’s true. You just never know if perhaps Rust compilers have some more advanced/modern tricks that can only be accessed easily by writing in Rust without writing assembly directly.
- pornel 2y ago
  There is a trick in truly exclusive references (marked noalias in LLVM). C++ doesn't even have the lesser form of C restrict pointers. However, a truly performance focused C or C++ library would tweak the code to get the desired optimizations one way or another. A more nebulous Rust perf thing is ability rely on the compiler to check lifetimes and immutability/exclusivity of pointers. This allows using fine-grained multithreading, even with 3rd party code, without the worry it's going to cause heisenbugs. It allows library APIs to work with temporary complex references that would be footguns otherwise (e.g. prefer string_view instead of string. Don't copy inputs defensively, because it's known they can't be mutated or freed even by a broken caller).
  - CuriousCosmic 2y ago
    > C++ doesn't even have the lesser form of C restrict pointers. Standard C++ doesn't but `noalias` is available in basically every major compiler (including the more niche embedded toolchains).
    - 3836293648 2y ago