7 ms·

These days I code primarily in C++, which is what Rust seemingly is designed to replace. It doesn't, as far as I can tell. I optimize directly for the hardware

These days I code primarily in C++, which is what Rust seemingly is designed to replace. It doesn't, as far as I can tell. I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical. It's great when something new and better comes along if that's really the case, but I've seen the "incrementally better in certain use cases" play many times before.

nitsky 4y ago
> I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical. What makes you think you can't control how memory is managed in Rust? Rust doesn't have "automatic" memory management, it has a compiler that can help ensure you are managing memory correctly, and force you to type "unsafe" when you are doing things it doesn't understand.
- Galanwe 4y ago
  > it has a compiler that can help ensure you are managing memory correctly, and force you to type "unsafe" when you are doing things it doesn't understand. Well it's a bit more subtle than that if we're honest. Arguably, Rust does make a number of memory layouts (self referential structs, per struct allocators, non thread local addresses, etc) much harder to accomplish than "typing unsafe".
  - wizzwizz4 4y ago
    If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers". Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48 https://github.com/rust-lang/wg-allocators/issues/48). Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).
    - Galanwe 4y ago
      > If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer. The only sane solution seems to be a generous sprinkle of Arcs, which is _not_ okay in high performance scenarios. > Per-struct allocators are a work in progress Yes, and most of us don't really want to use nightly in production. It's been years of work on the allocator work group already, and there's probably still years to wait before a stable release. > Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location. This is very very annoying to implement in Rust at the moment. Don't get me wrong though, I think Rust has a lot to offer. But when you dive in even slightly technical subjects in Rust, it soon becomes obvious that the power of C/C++ is far from "just type unsafe" away.
      - wizzwizz4 4y ago
        > I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer. You just do it. I can't recall a good example at the moment, so I've just thrown together a load of Cells: the thing I was doing when I learnt this technique didn't have any Cells in it. https://play.rust-lang.org/?version=nightly&edition=2021&gist=5311e37d1a6c6e80437bc690a1646c61 https://play.rust-lang.org/?version=nightly&edition=2021&gis... #[derive(Debug)] struct SlotMachine<'a> { slots: Vec<Cell<i32>>, current: Cell<Option<&'a Cell<i32>>>, } fn main() { let machine = SlotMachine { slots: vec![Cell::new(0); 5], current: Cell::new(None), }; machine.current.set(Some(&machine.slots[4])); machine.slots[4].set(12); println!("{:#?}", machine); } > Yes, and most of us don't really want to use nightly in production. Strictly speaking, this is only needed if you want to use Rust's standard library types with custom allocators. You've been able to have per-struct allocators for your own types since long before I learnt the language. > Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location. Can't you just store offsets into the memory region, and PhantomData references, then unsafely index the mmap'd region when you need an actual reference? Seems like the same thing you'd do in C, except the function you abstract that with can be a method instead. (Unless I'm still misunderstanding.)
- B8MGHCBekDuRi 4y ago
  > What makes you think you can't control how memory is managed in Rust? experienced C++ programmers says "Rust is great but very young and still C++ is better for my use case". Rust supporter replies "what makes you think you know better than us what it is better for you?" Welcoming community, they said.
  - Shish2k 4y ago
    Neither of those paraphrasings seem to line up with their source material
    - B8MGHCBekDuRi 4y ago
      Are you sure? Read again > I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical. > What makes you think you can't control how memory is managed in Rust? > Arguably, Rust does make a number of memory layouts (self referential structs, per struct allocators, non thread local addresses, etc) much harder to accomplish than "typing unsafe". So basically, the right question would be "can you explain what you mean that Rust can't control how memory is managed"? Because the author knew, the Rust supporter didn't and confused "work in progress" with "I need it now because I'm using it now in production in my daily job"
      - Shish2k 4y ago
        Yup, I’ve read it again, and I’m still pretty sure that you’re responding mostly to your own assumptions and not really responding to what was written :)
        B8MGHCBekDuRi 4y ago
        We've established that you lack the ability to understand a text, then.
k__ 4y ago
Interesting. As far as I know, the Rust developers consider performance worse than C a bug.
- sshine 4y ago
  At my current Rust job, we see a performance regression a CI failure.
pclmulqdq 4y ago
This has been my experience with Rust as well. The safety actually does cost some performance. Just like how C++'s "zero-cost" abstractions cost something. It seems like a straightforward trade between speed and safety to me, but nobody in the Rust community wants to admit it. As such, there aren't a lot of public benchmarks of applications out there that can help the rest of us figure out when we actually should use rust - when the performance is worth the safety (no, Rust evangelists, that kind of safety is not always worth it, and no, we don't always pay the same costs for it).
- junon 4y ago
  I understand exactly what you mean at the conceptual level, but I've consistently found speedups over c++ in complex applications.
  - pclmulqdq 4y ago
    There is a lot of C++ code out there. A lot of it was not written by people who understand performance or who care. It is very easy to take that kind of code and make it faster, even without a switch to Rust. The examples I have seen where a Rust rewrite is faster than original C++ code usually have glaring performance issues in the C++: Often, it is code that does a ton of unnecessary copies. The Rust code often doesn't copy as much because the Rust language makes that kind of copying inconvenient or because the person doing the rewrite is a Rust expert and not a C++ expert. The other kind of speedup I have seen is when people swap a C++ std::map for a Rust btree_map, and don't realize that absl::btree_map (a C++ btree map in Google's library) is what Rust's btree_map is based on. I haven't seen any examples where C or C++ code written with performance in mind gets a rewrite to Rust and goes faster, and I have seen the opposite.
    - herbstein 4y ago
      > There is a lot of C++ code out there. A lot of it was not written by people who understand performance or who care. It is very easy to take that kind of code and make it faster, even without a switch to Rust. Cliff Biffle's great series of blog posts called "Learn Rust the Dangerous Way" takes the fastest C program from a benchmark game entry, rewrites it naïvely in Rust using copious amounts of `unsafe`, and then transforms it into program without `unsafe` while keeping it idiomatic. The last version is faster than the C implementation. It's a toy example but it's real-world example. http://cliffle.com/p/dangerust/ http://cliffle.com/p/dangerust/
meghan_rain 4y ago
This can be done with Rust as well, using unsafe code block if absolutely necessary. And only those blocks have to be reviewed for footguns, as opposed to your entire C++ code. Also even a 10x speedup sounds much. In Rust, instead using .get_unchecked() (the C++ equivalent) instead of using .get() is typically only a neglegible improvement of a few percentage points in that particular loop or whatever.
junon 4y ago
In which cases do you not manage how memory is allocated in Rust?
lazypenguin 4y ago
I very much enjoy Rust and write a fair bit of C++ as well. I don’t think Rust will replace C++ completely but it will definitely significantly eat into its market share for certain types of applications. In the past if you absolutely needed a “modern” language and needed performance you’d basically only go C++ (or maybe C). IMO if you’re writing a highly concurrent or parallel application it’s hard to deny how much more productive and safer it is to write it in Rust. Optimizing cpu instructions in a single thread? Rust might just be an alternative and not competitive.
thegeomaster 4y ago
Same here. We do a lot of "trust me, it's OK" operations in the name of performance, like very complex ownership semantics, manually issuing memory barriers in multithreaded scenarios, etc. Can't do any of that in Rust. The borrow checker usually forces a different design which is conceptually simpler and has fewer assumptions baked in (you end up with quite a bit of Rc/Arc, RefCells, etc.) but sacrifices quite a lot of speed.
jjtheblunt 4y ago
10 - 100x vs what?
sshine 4y ago
> C++, which is what Rust seemingly is designed to replace. It doesn't, as far as I can tell. You can't replace C++: 1. Well-functioning, mission-critical systems that were made in C++ aren't being replaced. 2. Anything GPU and ML-related is still better solved in Python/C++. 3. Anything that depends on scalable, high-performance data structures, C++ still has a better selection. What "replace C++" can mean is: There are use-cases where Rust and C++ overlap where the Rust story is maturing, and you can pick Rust in those cases instead of C++ if you're not already invested in C++. But either if you have existing C++ code that works well, or you have deep C++ knowledge, or you are in one of the categories where Rust is not on par yet, there's still no competition.
- jenadine 4y ago
  > 1. Well-functioning, mission-critical systems that were made in C++ aren't being replaced. Very true. There is a lot of existing working code that is not going away and will even still need to be maintained for decades. > 2. Anything GPU and ML-related is still better solved in Python/C++. Can be done in Python/Rust > 3. Anything that depends on scalable, high-performance data structures, C++ still has a better selection. Why is that? Rust has equally high performance data structures. Even more perfortant in some cases (restrict by default, destructive move, easier concurrency)
  - sshine 4y ago
    > [Anything GPU and ML-related] Can be done in Python/Rust Can be done in Brainfuck. You just need to write the Cuda bindings. > > C++ still has a better selection. > Why is that? Because C++ was around for longer. For people who are more invested in Rust (myself included), extending Rust's selection is seen as a great endeavour. I personally keep a list of things I wish to "oxidize". :-)
mattgreenrocks 4y ago
There are definitely fringe edge cases where C++ can do things that Rust simply cannot, currently. I'm thinking of things like Herb Sutter's deferred_heap (https://github.com/hsutter/gcpp https://github.com/hsutter/gcpp) that give you GC-like abstraction. It's pretty cool that this is possible to write in vanilla C++ with decent ergonomics. I tried to make something similar awhile back in Rust and hit a wall in terms of making something that would be pleasant to use. Rust has several on-going experiments with making a nice GC, along with good support for arenas. (If you can use arenas, they're great.)
pornel 4y ago
Are you sure you're not confusing it with Swift, or perhaps running Rust in unoptimized debug mode (-O0)? Rust goes as low-level as C (there's literally c2rust source-to-source translator). It gives you full control over all allocations and indirections. It's even more efficient than C++ in a few places, e.g. it has a more efficient ABI for unique_ptr, doesn't call destructors redundantly after a move, doesn't need isa pointer in structs with virtual methods. Rust generates native code using LLVM, and even has a bit stricter semantics that allow better optimizations (notably immutability and mutable aliasing are stricter than in C and C++).
ModernMech 4y ago
You're probably running Rust code in debug mode, or something else is going on. Without more info, hard to say. But for tasks where the purpose is to write the fastest code possible, Rust is very competitive and regularly outperforms C and C++. Sure there are perf differences, but 10-100x figures are unheard of unless you're doing something really wrong. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
lordnacho 4y ago
Having written both my sense is that C++ will indeed be ultimately faster, but with a lot of work. You can get pretty close with Rust, with less pulling your hair out, and much faster coding time. Whether that's worth the difference to a fully optimized C++ depends on what you're up to.

nitsky 4y ago

> I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical. What makes you think you can't control how memory is managed in Rust? Rust doesn't have "automatic" memory management, it has a compiler that can help ensure you are managing memory correctly, and force you to type "unsafe" when you are doing things it doesn't understand.

Galanwe 4y ago
> it has a compiler that can help ensure you are managing memory correctly, and force you to type "unsafe" when you are doing things it doesn't understand. Well it's a bit more subtle than that if we're honest. Arguably, Rust does make a number of memory layouts (self referential structs, per struct allocators, non thread local addresses, etc) much harder to accomplish than "typing unsafe".
- wizzwizz4 4y ago
  If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers". Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48 https://github.com/rust-lang/wg-allocators/issues/48). Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).
  - Galanwe 4y ago
    > If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer. The only sane solution seems to be a generous sprinkle of Arcs, which is _not_ okay in high performance scenarios. > Per-struct allocators are a work in progress Yes, and most of us don't really want to use nightly in production. It's been years of work on the allocator work group already, and there's probably still years to wait before a stable release. > Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location. This is very very annoying to implement in Rust at the moment. Don't get me wrong though, I think Rust has a lot to offer. But when you dive in even slightly technical subjects in Rust, it soon becomes obvious that the power of C/C++ is far from "just type unsafe" away.
    - wizzwizz4 4y ago
      > I have a hard time seeing how you could use self references without a combination of raw pointers, pins/projects, and unsafe code. The tediousness of doing so is pretty much a no-go for any sane developer. You just do it. I can't recall a good example at the moment, so I've just thrown together a load of Cells: the thing I was doing when I learnt this technique didn't have any Cells in it. https://play.rust-lang.org/?version=nightly&edition=2021&gist=5311e37d1a6c6e80437bc690a1646c61 https://play.rust-lang.org/?version=nightly&edition=2021&gis... #[derive(Debug)] struct SlotMachine<'a> { slots: Vec<Cell<i32>>, current: Cell<Option<&'a Cell<i32>>>, } fn main() { let machine = SlotMachine { slots: vec![Cell::new(0); 5], current: Cell::new(None), }; machine.current.set(Some(&machine.slots[4])); machine.slots[4].set(12); println!("{:#?}", machine); } > Yes, and most of us don't really want to use nightly in production. Strictly speaking, this is only needed if you want to use Rust's standard library types with custom allocators. You've been able to have per-struct allocators for your own types since long before I learnt the language. > Well I mean overall any way to allow a somewhat eased setup for storing and retrieving objects to/from shared memory, across processes that do not map said memory at the same location. Can't you just store offsets into the memory region, and PhantomData references, then unsafely index the mmap'd region when you need an actual reference? Seems like the same thing you'd do in C, except the function you abstract that with can be a method instead. (Unless I'm still misunderstanding.)
B8MGHCBekDuRi 4y ago
> What makes you think you can't control how memory is managed in Rust? experienced C++ programmers says "Rust is great but very young and still C++ is better for my use case". Rust supporter replies "what makes you think you know better than us what it is better for you?" Welcoming community, they said.
- Shish2k 4y ago
  Neither of those paraphrasings seem to line up with their source material
  - B8MGHCBekDuRi 4y ago
    Are you sure? Read again > I optimize directly for the hardware I'm running on, which typically gives me 10-100x performance improvements. Controlling how memory is managed is critical. > What makes you think you can't control how memory is managed in Rust? > Arguably, Rust does make a number of memory layouts (self referential structs, per struct allocators, non thread local addresses, etc) much harder to accomplish than "typing unsafe". So basically, the right question would be "can you explain what you mean that Rust can't control how memory is managed"? Because the author knew, the Rust supporter didn't and confused "work in progress" with "I need it now because I'm using it now in production in my daily job"
    - Shish2k 4y ago
      Yup, I’ve read it again, and I’m still pretty sure that you’re responding mostly to your own assumptions and not really responding to what was written :)
      - B8MGHCBekDuRi 4y ago
        We've established that you lack the ability to understand a text, then.

k__ 4y ago

Interesting. As far as I know, the Rust developers consider performance worse than C a bug.

sshine 4y ago
At my current Rust job, we see a performance regression a CI failure.

pclmulqdq 4y ago

This has been my experience with Rust as well. The safety actually does cost some performance. Just like how C++'s "zero-cost" abstractions cost something. It seems like a straightforward trade between speed and safety to me, but nobody in the Rust community wants to admit it. As such, there aren't a lot of public benchmarks of applications out there that can help the rest of us figure out when we actually should use rust - when the performance is worth the safety (no, Rust evangelists, that kind of safety is not always worth it, and no, we don't always pay the same costs for it).

junon 4y ago
I understand exactly what you mean at the conceptual level, but I've consistently found speedups over c++ in complex applications.
- pclmulqdq 4y ago
  There is a lot of C++ code out there. A lot of it was not written by people who understand performance or who care. It is very easy to take that kind of code and make it faster, even without a switch to Rust. The examples I have seen where a Rust rewrite is faster than original C++ code usually have glaring performance issues in the C++: Often, it is code that does a ton of unnecessary copies. The Rust code often doesn't copy as much because the Rust language makes that kind of copying inconvenient or because the person doing the rewrite is a Rust expert and not a C++ expert. The other kind of speedup I have seen is when people swap a C++ std::map for a Rust btree_map, and don't realize that absl::btree_map (a C++ btree map in Google's library) is what Rust's btree_map is based on. I haven't seen any examples where C or C++ code written with performance in mind gets a rewrite to Rust and goes faster, and I have seen the opposite.
  - herbstein 4y ago
    > There is a lot of C++ code out there. A lot of it was not written by people who understand performance or who care. It is very easy to take that kind of code and make it faster, even without a switch to Rust. Cliff Biffle's great series of blog posts called "Learn Rust the Dangerous Way" takes the fastest C program from a benchmark game entry, rewrites it naïvely in Rust using copious amounts of `unsafe`, and then transforms it into program without `unsafe` while keeping it idiomatic. The last version is faster than the C implementation. It's a toy example but it's real-world example. http://cliffle.com/p/dangerust/ http://cliffle.com/p/dangerust/

meghan_rain 4y ago

This can be done with Rust as well, using unsafe code block if absolutely necessary. And only those blocks have to be reviewed for footguns, as opposed to your entire C++ code. Also even a 10x speedup sounds much. In Rust, instead using .get_unchecked() (the C++ equivalent) instead of using .get() is typically only a neglegible improvement of a few percentage points in that particular loop or whatever.

junon 4y ago

In which cases do you not manage how memory is allocated in Rust?

lazypenguin 4y ago

I very much enjoy Rust and write a fair bit of C++ as well. I don’t think Rust will replace C++ completely but it will definitely significantly eat into its market share for certain types of applications. In the past if you absolutely needed a “modern” language and needed performance you’d basically only go C++ (or maybe C). IMO if you’re writing a highly concurrent or parallel application it’s hard to deny how much more productive and safer it is to write it in Rust. Optimizing cpu instructions in a single thread? Rust might just be an alternative and not competitive.

thegeomaster 4y ago

Same here. We do a lot of "trust me, it's OK" operations in the name of performance, like very complex ownership semantics, manually issuing memory barriers in multithreaded scenarios, etc. Can't do any of that in Rust. The borrow checker usually forces a different design which is conceptually simpler and has fewer assumptions baked in (you end up with quite a bit of Rc/Arc, RefCells, etc.) but sacrifices quite a lot of speed.

jjtheblunt 4y ago

10 - 100x vs what?

sshine 4y ago

> C++, which is what Rust seemingly is designed to replace. It doesn't, as far as I can tell. You can't replace C++: 1. Well-functioning, mission-critical systems that were made in C++ aren't being replaced. 2. Anything GPU and ML-related is still better solved in Python/C++. 3. Anything that depends on scalable, high-performance data structures, C++ still has a better selection. What "replace C++" can mean is: There are use-cases where Rust and C++ overlap where the Rust story is maturing, and you can pick Rust in those cases instead of C++ if you're not already invested in C++. But either if you have existing C++ code that works well, or you have deep C++ knowledge, or you are in one of the categories where Rust is not on par yet, there's still no competition.

jenadine 4y ago
> 1. Well-functioning, mission-critical systems that were made in C++ aren't being replaced. Very true. There is a lot of existing working code that is not going away and will even still need to be maintained for decades. > 2. Anything GPU and ML-related is still better solved in Python/C++. Can be done in Python/Rust > 3. Anything that depends on scalable, high-performance data structures, C++ still has a better selection. Why is that? Rust has equally high performance data structures. Even more perfortant in some cases (restrict by default, destructive move, easier concurrency)
- sshine 4y ago
  > [Anything GPU and ML-related] Can be done in Python/Rust Can be done in Brainfuck. You just need to write the Cuda bindings. > > C++ still has a better selection. > Why is that? Because C++ was around for longer. For people who are more invested in Rust (myself included), extending Rust's selection is seen as a great endeavour. I personally keep a list of things I wish to "oxidize". :-)

mattgreenrocks 4y ago

There are definitely fringe edge cases where C++ can do things that Rust simply cannot, currently. I'm thinking of things like Herb Sutter's deferred_heap (https://github.com/hsutter/gcpp https://github.com/hsutter/gcpp) that give you GC-like abstraction. It's pretty cool that this is possible to write in vanilla C++ with decent ergonomics. I tried to make something similar awhile back in Rust and hit a wall in terms of making something that would be pleasant to use. Rust has several on-going experiments with making a nice GC, along with good support for arenas. (If you can use arenas, they're great.)

pornel 4y ago

Are you sure you're not confusing it with Swift, or perhaps running Rust in unoptimized debug mode (-O0)? Rust goes as low-level as C (there's literally c2rust source-to-source translator). It gives you full control over all allocations and indirections. It's even more efficient than C++ in a few places, e.g. it has a more efficient ABI for unique_ptr, doesn't call destructors redundantly after a move, doesn't need isa pointer in structs with virtual methods. Rust generates native code using LLVM, and even has a bit stricter semantics that allow better optimizations (notably immutability and mutable aliasing are stricter than in C and C++).

ModernMech 4y ago

You're probably running Rust code in debug mode, or something else is going on. Without more info, hard to say. But for tasks where the purpose is to write the fastest code possible, Rust is very competitive and regularly outperforms C and C++. Sure there are perf differences, but 10-100x figures are unheard of unless you're doing something really wrong. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

lordnacho 4y ago

Having written both my sense is that C++ will indeed be ultimately faster, but with a lot of work. You can get pretty close with Rust, with less pulling your hair out, and much faster coding time. Whether that's worth the difference to a fully optimized C++ depends on what you're up to.