3 ms·

Honest question - does this mean Rust isn't ready for production yet?

by ape4 4y ago

msbarnett 4y ago
No. TFA points out there isn’t a gigantic performance sink or anything, just an infelicity in the code they’re generating. >> Does this mean Rust is slower than C++? > No. You can always write your Rust code carefully to avoid copies. Besides, all of this only comes out to a small percentage of the total instruction count. That being said, it's something we should fix, and which I'm working on.
- tialaramex 4y ago
  As pointed out elsewhere in this comment tree, things living on the stack when they needn't can mean they don't fit and thus the program doesn't work, so the optimisation can matter for that reason, and this is a particular reason to worry about it for larger objects where the optimiser is more likely not to see what's going on.
  - msbarnett 4y ago
    And yet, real world production rust programs exist and measured performance is generally excellent. People are acting like this graph they saw for the first time today means that Rust is running at sub-Ruby speeds, when even with these excess copies we already know, and have known for years how rust programs have been performing in real life. That there is room for improvement here does not mean that the status quo was not already excellent.
    - germandiago 4y ago
      > People are acting like this graph they saw for the first time today means that Rust is running at sub-Ruby speeds Well, this is no different of how Rust people talk about C++ as if it was as unsafe as if you were writing inline assembly :)
pcwalton 4y ago
No. Lots of people are happily running Rust in production and getting significant value from it.
insanitybit 4y ago
It is totally unrelated to production readiness. This is just trying to address and understand a cost in Rust that ideally wouldn't exist. The cost exists in C++ too, but Rust uses move semantics much more aggressively vs reference forwarding.

Honest question - does this mean Rust isn't ready for production yet?

by ape4 4y ago

Honest question - does this mean Rust isn't ready for production yet?

No. TFA points out there isn’t a gigantic performance sink or anything, just an infelicity in the code they’re generating. >> Does this mean Rust is slower than C++? > No. You can always write your Rust code carefully to avoid copies. Besides, all of this only comes out to a small percentage of the total instruction count. That being said, it's something we should fix, and which I'm working on.

tialaramex 4y ago
As pointed out elsewhere in this comment tree, things living on the stack when they needn't can mean they don't fit and thus the program doesn't work, so the optimisation can matter for that reason, and this is a particular reason to worry about it for larger objects where the optimiser is more likely not to see what's going on.
- msbarnett 4y ago
  And yet, real world production rust programs exist and measured performance is generally excellent. People are acting like this graph they saw for the first time today means that Rust is running at sub-Ruby speeds, when even with these excess copies we already know, and have known for years how rust programs have been performing in real life. That there is room for improvement here does not mean that the status quo was not already excellent.
  - germandiago 4y ago
    > People are acting like this graph they saw for the first time today means that Rust is running at sub-Ruby speeds Well, this is no different of how Rust people talk about C++ as if it was as unsafe as if you were writing inline assembly :)

pcwalton 4y ago

No. Lots of people are happily running Rust in production and getting significant value from it.

insanitybit 4y ago

It is totally unrelated to production readiness. This is just trying to address and understand a cost in Rust that ideally wouldn't exist. The cost exists in C++ too, but Rust uses move semantics much more aggressively vs reference forwarding.