4 ms·

The related post on performance optimization is extremely interesting, in particular, the considerations drawn while moving from the unsafe ported code to safe¹

The related post on performance optimization is extremely interesting, in particular, the considerations drawn while moving from the unsafe ported code to safe¹: > The first performance issue we hit was dynamic dispatch to assembly, as these calls are very hot. We then began adding inner mutability when necessary but had to carefully avoid contention. We found as we removed pointers and transitioned to safe Rust types that bounds checks increasingly became a larger factor. Buffer and structure initialization was also an issue as we migrated to safe, owned Rust types. Based on their conclusions², each of those issues amounts to a few percentage points (total: 11%). Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance, and it can be very hard to compensate (withing the safety requirements). [¹]: https://www.memorysafety.org/blog/rav1d-performance-optimization/#optimization-process https://www.memorysafety.org/blog/rav1d-performance-optimiza... [²]: https://www.memorysafety.org/blog/rav1d-performance-optimization/#current-state https://www.memorysafety.org/blog/rav1d-performance-optimiza...

deleted 1y ago
[deleted]
StopDisinfo910 1y ago
> Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance, and it can be very hard to compensate (withing the safety requirements). In Rust. These are Rust issues, not issues with safety in general. The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization. The core issue is that the strategies Rust adopts to ensure memory safety are neither a panacea nor necessarily the right solution in every case. That being said, I think it's a very nice idea to try to write a decoder in Rust and have a bounty for optimization. Rust is popular so work on producing fast and safe Rust is good.
- pizza234 1y ago
  > The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization. The situation is more nuanced. The article dedicates a section to it: > The general idea in eliding unnecessary bounds checks was that we needed to expose as much information about indices and slice bounds to the compiler as possible. We found many cases where we knew, from global context, that indices were guaranteed to be in range, but the compiler could not infer this only from local information (even with inlining). Most of our effort to elide bounds checks went into exposing additional context to buffer accesses. (extensive information given in that section)
  - immibis 1y ago
    I think the comment you replied to is about a different approach: writing the algorithm in assembly or C, and then proving it doesn't access anything out of bounds. This is the WUFFS approach, for example. Formal verification, while very cool, is extremely tedious, which is why more practical languages try to find compromise rules that are simpler to implement, while also not too limiting.
- HPsquared 1y ago
  If there isn't already a name for this compile-time safety checking in Rust, I vote we call it "passivation".
- HideousKojima 1y ago
  >The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization. You can't always know the bounds at compile time, though.
  - anon-3988 1y ago
    If the compiler is smart enough and the code is written in the right way, the compiler should be able to omit a lot of bounds check. This is much easier to achieve in Rust (safely) because of noaliasing by default.
    - HideousKojima 1y ago
      Sure, but the post I replied to claimed bounds check issues were entirely avoidable at compile time
      - StopDisinfo910 1y ago
        Bound checks are entirely avoidable if you can prove that all your calls are within bounds - this being the key part of my comment. If you can’t, you just rewrite your code so you can because your code is not safe otherwise and safe code is what we are discussing here. Note that all calls can trivially be made provably within bounds by explicitly bound checking yourself and providing an alternate path for out of bound calls which obviously doesn’t improve performances compared to bound checks inserted by the compiler but at least save you a panic in the worst case scenario.
steveklabnik 1y ago
> Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance You cannot draw general conclusions by the experiences of one project one time. There are too many confounding factors. There are also projects who have experienced the opposite.

deleted 1y ago

[deleted]

StopDisinfo910 1y ago

> Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance, and it can be very hard to compensate (withing the safety requirements). In Rust. These are Rust issues, not issues with safety in general. The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization. The core issue is that the strategies Rust adopts to ensure memory safety are neither a panacea nor necessarily the right solution in every case. That being said, I think it's a very nice idea to try to write a decoder in Rust and have a bounty for optimization. Rust is popular so work on producing fast and safe Rust is good.

pizza234 1y ago
> The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization. The situation is more nuanced. The article dedicates a section to it: > The general idea in eliding unnecessary bounds checks was that we needed to expose as much information about indices and slice bounds to the compiler as possible. We found many cases where we knew, from global context, that indices were guaranteed to be in range, but the compiler could not infer this only from local information (even with inlining). Most of our effort to elide bounds checks went into exposing additional context to buffer accesses. (extensive information given in that section)
- immibis 1y ago
  I think the comment you replied to is about a different approach: writing the algorithm in assembly or C, and then proving it doesn't access anything out of bounds. This is the WUFFS approach, for example. Formal verification, while very cool, is extremely tedious, which is why more practical languages try to find compromise rules that are simpler to implement, while also not too limiting.
HPsquared 1y ago
If there isn't already a name for this compile-time safety checking in Rust, I vote we call it "passivation".
HideousKojima 1y ago
>The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization. You can't always know the bounds at compile time, though.
- anon-3988 1y ago
  If the compiler is smart enough and the code is written in the right way, the compiler should be able to omit a lot of bounds check. This is much easier to achieve in Rust (safely) because of noaliasing by default.
  - HideousKojima 1y ago
    Sure, but the post I replied to claimed bounds check issues were entirely avoidable at compile time
    - StopDisinfo910 1y ago
      Bound checks are entirely avoidable if you can prove that all your calls are within bounds - this being the key part of my comment. If you can’t, you just rewrite your code so you can because your code is not safe otherwise and safe code is what we are discussing here. Note that all calls can trivially be made provably within bounds by explicitly bound checking yourself and providing an alternate path for out of bound calls which obviously doesn’t improve performances compared to bound checks inserted by the compiler but at least save you a panic in the worst case scenario.

steveklabnik 1y ago

> Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance You cannot draw general conclusions by the experiences of one project one time. There are too many confounding factors. There are also projects who have experienced the opposite.