3 ms·

While I can't name the product I work on, we also use -fno-strict-aliasing. The problem with these optimisations is that they can only be done safely if you can

by Asooka 1y ago

While I can't name the product I work on, we also use -fno-strict-aliasing. The problem with these optimisations is that they can only be done safely if you can prove aliasing never happens, which is equivalent to solving the halting problem in C++. In Rust I suspect the stronger type system can actually prove that aliasing doesn't happen in select cases. In any case, I can always manually do the optimisations enabled by strict aliasing in hot code, but I can never undo a customer losing data due to miscompilation.

pornel 1y ago
> actually prove that aliasing doesn't happen in select cases In the safe subset of Rust it's guaranteed in all cases. Even across libraries. Even in multi-threaded code.
- oconnor663 1y ago
  To elaborate on that some more, safe Rust can guarantee that mutable aliasing never happens, without solving the halting program, because it forbids some programs that could've been considered legal. Here's an example of a function that's allowed: fn foo() { let mut x = 42; let mut mutable_references = Vec::new(); let test: bool = rand::random(); if test { mutable_references.push(&mut x); } else { mutable_references.push(&mut x); } } Because only one if/else branch is ever allowed to execute, the compiler can see "lexically" that only one mutable reference to `x` is created, and `foo` compiles. But this other function that's "obviously" equivalent doesn't compile: fn bar() { let mut x = 42; let mut mutable_references = Vec::new(); let test: bool = rand::random(); if test { mutable_references.push(&mut x); } if !test { mutable_references.push(&mut x); // error: cannot borrow `x` as mutable more than once at a time } } The Rust compiler doesn't do the analysis necessary to see that only one of those branches can execute, so it conservatively assumes that both of them can, and it refuses to compile `bar`. To do things like `bar`, you have to either refactor them to look more like `foo`, or else you have to use `unsafe` code.
  - deleted 1y ago
    [deleted]
- gronpi 1y ago
  It requires that the libraries you use do not have UB. If you have no unsafe, but your library does, you can get UB. https://github.com/rust-lang/rust/pull/139553 https://github.com/rust-lang/rust/pull/139553 This is why it may be a good idea to run MIRI on your Rust code, even when it has no unsafe, since a library like Rust stdlib might have UB.
  - simonask 1y ago
    Isn't this a pretty trivial observation, though? All code everywhere relies on the absence of UB. The strength of Rust comes from the astronomically better tools to avoid UB, including Miri.
    - gryhili 1y ago
      Miri is good, but it still has very significant large limitations. And the recommendation of using Miri is unlikely to apply to using similar tools for many other programming languages, given the state of UB in the Rust ecosystem, as recommended by https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-... https://zackoverflow.dev/writing/unsafe-rust-vs-zig https://zackoverflow.dev/writing/unsafe-rust-vs-zig >If you use a crate in your Rust program, Miri will also panic if that crate has some UB. This sucks because there’s no way to configure it to skip over the crate, so you either have to fork and patch the UB yourself, or raise an issue with the authors of the crates and hopefully they fix it. >This happened to me once on another project and I waited a day for it to get fixed, then when it was finally fixed I immediately ran into another source of UB from another crate and gave up. Further, Miri is slow to run, discouraging people to use it even for the subset of cases that it can catch UB. >The interpreter isn’t exactly fast, from what I’ve observed it’s more than 400x slower. Regular Rust can run the tests I wrote in less than a second, but Miri takes several minutes. If Miri runs 50x slower than normal code, it can limit what code paths people will run it with. So, while I can imagine that Miri could be best in class, that class itself has significant limitations.
      - ralfj 1y ago
immibis 1y ago
> which is equivalent to solving the halting problem Most worthwhile undefined behaviour is. If the compiler could tell whether it was happening or not, it would be defined as an error. Surely detecting whether a tree borrow violation happens is also equivalent to solving the halting problem?

by Asooka 1y ago

pornel 1y ago

> actually prove that aliasing doesn't happen in select cases In the safe subset of Rust it's guaranteed in all cases. Even across libraries. Even in multi-threaded code.

oconnor663 1y ago
To elaborate on that some more, safe Rust can guarantee that mutable aliasing never happens, without solving the halting program, because it forbids some programs that could've been considered legal. Here's an example of a function that's allowed: fn foo() { let mut x = 42; let mut mutable_references = Vec::new(); let test: bool = rand::random(); if test { mutable_references.push(&mut x); } else { mutable_references.push(&mut x); } } Because only one if/else branch is ever allowed to execute, the compiler can see "lexically" that only one mutable reference to `x` is created, and `foo` compiles. But this other function that's "obviously" equivalent doesn't compile: fn bar() { let mut x = 42; let mut mutable_references = Vec::new(); let test: bool = rand::random(); if test { mutable_references.push(&mut x); } if !test { mutable_references.push(&mut x); // error: cannot borrow `x` as mutable more than once at a time } } The Rust compiler doesn't do the analysis necessary to see that only one of those branches can execute, so it conservatively assumes that both of them can, and it refuses to compile `bar`. To do things like `bar`, you have to either refactor them to look more like `foo`, or else you have to use `unsafe` code.
- deleted 1y ago
  [deleted]
gronpi 1y ago
It requires that the libraries you use do not have UB. If you have no unsafe, but your library does, you can get UB. https://github.com/rust-lang/rust/pull/139553 https://github.com/rust-lang/rust/pull/139553 This is why it may be a good idea to run MIRI on your Rust code, even when it has no unsafe, since a library like Rust stdlib might have UB.
- simonask 1y ago
  Isn't this a pretty trivial observation, though? All code everywhere relies on the absence of UB. The strength of Rust comes from the astronomically better tools to avoid UB, including Miri.
  - gryhili 1y ago
    Miri is good, but it still has very significant large limitations. And the recommendation of using Miri is unlikely to apply to using similar tools for many other programming languages, given the state of UB in the Rust ecosystem, as recommended by https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-... https://zackoverflow.dev/writing/unsafe-rust-vs-zig https://zackoverflow.dev/writing/unsafe-rust-vs-zig >If you use a crate in your Rust program, Miri will also panic if that crate has some UB. This sucks because there’s no way to configure it to skip over the crate, so you either have to fork and patch the UB yourself, or raise an issue with the authors of the crates and hopefully they fix it. >This happened to me once on another project and I waited a day for it to get fixed, then when it was finally fixed I immediately ran into another source of UB from another crate and gave up. Further, Miri is slow to run, discouraging people to use it even for the subset of cases that it can catch UB. >The interpreter isn’t exactly fast, from what I’ve observed it’s more than 400x slower. Regular Rust can run the tests I wrote in less than a second, but Miri takes several minutes. If Miri runs 50x slower than normal code, it can limit what code paths people will run it with. So, while I can imagine that Miri could be best in class, that class itself has significant limitations.
    - ralfj 1y ago

immibis 1y ago

> which is equivalent to solving the halting problem Most worthwhile undefined behaviour is. If the compiler could tell whether it was happening or not, it would be defined as an error. Surely detecting whether a tree borrow violation happens is also equivalent to solving the halting problem?