4 ms·

> 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

> 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.

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.