3 ms·

Of course it DOES hurt performance. Anyone who tells you it does not is wrong. There are no zero-cost abstractions. https://godbolt.org/z/dvxhnqbeW https://god

by expnkx 5y ago

Of course it DOES hurt performance. Anyone who tells you it does not is wrong. There are no zero-cost abstractions. https://godbolt.org/z/dvxhnqbeW https://godbolt.org/z/dvxhnqbeW https://godbolt.org/z/4q8ej77Ke https://godbolt.org/z/4q8ej77Ke Shows rust generates 10x more instructions than C++ due to panic messages and optimizations hurting.

matesz 5y ago
I would like to somehow raise your comment higher becase example you've posted is so simple and clear. Is it possible to make Rust implementation to be on par with C++ in terms of performance for that particular example without using unsafe?
- mlindner 5y ago
  The C++ example is incredibly unsafe as it's not doing any bounds checking so the comparison isn't even fair. You wouldn't write code that way in C++ unless you have some kind of absolute trust in the caller and the slice was of known fixed size and it was impossible that refactoring would never change the size. Here's a fair comparison with C++: https://godbolt.org/z/qh5n49Y69 https://godbolt.org/z/qh5n49Y69 https://godbolt.org/z/rdET7aT5d https://godbolt.org/z/rdET7aT5d As you can see the Rust version is faster (the only major difference is Rust embeds more information about the panic locations rather than having a single shared message for the exception). In either case though I wouldn't write the Rust or C++ that way, I'd write a single expression that filled in all the values at once rather than doing them line by line after checking the size a single time. Rust can then elide the bounds check if it knows that you already checked. In Rust and C++ you would should use iterators via for-each loops or a single statement initializer. (If you want, you can use unsafe and get identical performance to the C++ version using .get_unchecked())
  - matesz 5y ago
    That is amazing, thanks!
    - mlindner 5y ago
      Here's the identical result to the C++ output, for reference. https://godbolt.org/z/6sa3zf555 https://godbolt.org/z/6sa3zf555
  - expnkx 5y ago
    If you want safety. you can just use _GLIBCXX_ASSERTIONS https://godbolt.org/z/eThdeW3Mv https://godbolt.org/z/eThdeW3Mv It gives you all bounds checking you need. In fact, a lot of Linux distributions (like Fedora) built all packages with _GLIBCXX_ASSERTIONS by default.
- labawi 5y ago
  If you want it safe, then the C++ version should also add a (single) length check. To fix rust's multiple points of failure, move the check to the top, by add something like 'let length_check = slice[5]', moving the 'slice[5]=5' to the top (or something nicer, don't know rust), and you will get only a single point of failure and a single check, same as safe C++ with matching API. If you want to have 0 runtime checks, like the C++ example, you can 1) make it unsafe and actively dangerous, like the C++ version 2) change the API so minimum length is guaranteed (probably possible in rust, harder in C++) 3) have the function private/inline where sufficient length is known/can be deduced and the check will be omitted
  - expnkx 5y ago
    If you want safety. you can just use _GLIBCXX_ASSERTIONS https://godbolt.org/z/eThdeW3Mv https://godbolt.org/z/eThdeW3Mv It gives you all bounds checking you need. In fact, a lot of Linux distributions (like Fedora) built all packages with _GLIBCXX_ASSERTIONS by default.
- newpavlov 5y ago
  In performance sensitive code without getting into unsafe you would write this function like this: https://godbolt.org/z/PTsnTMq7M https://godbolt.org/z/PTsnTMq7M Effectively it results in the same assembly as for the completely unsafe C++ code, apart from the 3 instructions which test slice length. During normal operation they are trivial for branch predictor, so their impact will be negligible in the most cases (but not always, e.g. if this function is part of a hot loop, but then inlining should come to the rescue) and in many cases this check will be removed if compiler is able to prove that the condition is always true. So in the worst case scenario you will lose several cycles on the test instructions and the panic code may slightly increase pressure on I-cache, which I think is a good price to pay for the safety.

by expnkx 5y ago

matesz 5y ago

I would like to somehow raise your comment higher becase example you've posted is so simple and clear. Is it possible to make Rust implementation to be on par with C++ in terms of performance for that particular example without using unsafe?

mlindner 5y ago
The C++ example is incredibly unsafe as it's not doing any bounds checking so the comparison isn't even fair. You wouldn't write code that way in C++ unless you have some kind of absolute trust in the caller and the slice was of known fixed size and it was impossible that refactoring would never change the size. Here's a fair comparison with C++: https://godbolt.org/z/qh5n49Y69 https://godbolt.org/z/qh5n49Y69 https://godbolt.org/z/rdET7aT5d https://godbolt.org/z/rdET7aT5d As you can see the Rust version is faster (the only major difference is Rust embeds more information about the panic locations rather than having a single shared message for the exception). In either case though I wouldn't write the Rust or C++ that way, I'd write a single expression that filled in all the values at once rather than doing them line by line after checking the size a single time. Rust can then elide the bounds check if it knows that you already checked. In Rust and C++ you would should use iterators via for-each loops or a single statement initializer. (If you want, you can use unsafe and get identical performance to the C++ version using .get_unchecked())
- matesz 5y ago
  That is amazing, thanks!
  - mlindner 5y ago
    Here's the identical result to the C++ output, for reference. https://godbolt.org/z/6sa3zf555 https://godbolt.org/z/6sa3zf555
- expnkx 5y ago
  If you want safety. you can just use _GLIBCXX_ASSERTIONS https://godbolt.org/z/eThdeW3Mv https://godbolt.org/z/eThdeW3Mv It gives you all bounds checking you need. In fact, a lot of Linux distributions (like Fedora) built all packages with _GLIBCXX_ASSERTIONS by default.
labawi 5y ago
If you want it safe, then the C++ version should also add a (single) length check. To fix rust's multiple points of failure, move the check to the top, by add something like 'let length_check = slice[5]', moving the 'slice[5]=5' to the top (or something nicer, don't know rust), and you will get only a single point of failure and a single check, same as safe C++ with matching API. If you want to have 0 runtime checks, like the C++ example, you can 1) make it unsafe and actively dangerous, like the C++ version 2) change the API so minimum length is guaranteed (probably possible in rust, harder in C++) 3) have the function private/inline where sufficient length is known/can be deduced and the check will be omitted
- expnkx 5y ago
  If you want safety. you can just use _GLIBCXX_ASSERTIONS https://godbolt.org/z/eThdeW3Mv https://godbolt.org/z/eThdeW3Mv It gives you all bounds checking you need. In fact, a lot of Linux distributions (like Fedora) built all packages with _GLIBCXX_ASSERTIONS by default.
newpavlov 5y ago
In performance sensitive code without getting into unsafe you would write this function like this: https://godbolt.org/z/PTsnTMq7M https://godbolt.org/z/PTsnTMq7M Effectively it results in the same assembly as for the completely unsafe C++ code, apart from the 3 instructions which test slice length. During normal operation they are trivial for branch predictor, so their impact will be negligible in the most cases (but not always, e.g. if this function is part of a hot loop, but then inlining should come to the rescue) and in many cases this check will be removed if compiler is able to prove that the condition is always true. So in the worst case scenario you will lose several cycles on the test instructions and the panic code may slightly increase pressure on I-cache, which I think is a good price to pay for the safety.