33 ms·

I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.

vvanders 6y ago
Have you ever used restrict in anger? I've done it when we really needed that performance for an inner loop(particle system). It can be a real bastard to keep the non-alias constraint held constant in a large, multi-person codebase and the error cases are really gnarly to chase down. Compare that to Rust which has this knowledge built in since it naturally falls out of the ownership model.
- Gibbon1 6y ago
  I agree with that, no aliasing in C is an ugly kludge that bitches about perfectly fine code that benefit benefit from it. And it's hard insure that it actually works in code that does. Worse the failure is completely silent.
  - jart 6y ago
    Is there something special about the noalias keyword that it really brings out the most unprofessional pig language in developers? https://www.lysator.liu.se/c/dmr-on-noalias.html https://www.lysator.liu.se/c/dmr-on-noalias.html
- cma 6y ago
  When people use the unsafe keyword are they always taking into account aliasing? At least you can audit only those places though.
  - zamalek 6y ago
    Yeah, `unsafe` is the developer signing a contract to uphold all the guarantees that safe rustc provided (at least from the perspective of the public interface, the invariants can be broken in private code). That's why Rust developers don't take kindly to unnecessary unsafe usage, because the audit surface area (and interaction complexity) increases.
    - millstone 6y ago
      But this is the crux. What sorts of aliasing are permitted in unsafe Rust? I think we kind of don't know; that's what the "stacked borrow" effort is trying to answer.
      - aliceryhl 6y ago
        We know pretty well for the vast majority of patterns whether it violates the aliasing rules or not. There may be some corner cases that are not yet decided on, but if you just consider those as UB for now, you are perfectly fine.
  - slaymaker1907 6y ago
    Rust takes const with pointers very seriously. It is undefined behavior to mutate anything non-mut (pointer or reference) unless it is through an UnsafeCell. While you can break compiler guarantees through pointers in Rust, dereferencing this pointers must still obey the above guarantee (basically think of it as you need to go back to references to actually use the aliased pointers which would be undefined due to the aliasing). Therefore, the optimizer can always assume mutations don't alias. Even UnsafeCell isn't allowed to break the alias rules, it just provides flexibility going from immutable to mutable.
    - millstone 6y ago
      What you describe about 'const' is just about const correctness. That's important but different than aliasing. For example consider Slice::swap [1]. This does consider the possibility that the pointers alias, and correctly, because they might point at the same object. https://doc.rust-lang.org/src/core/slice/mod.rs.html#541-553 https://doc.rust-lang.org/src/core/slice/mod.rs.html#541-553
      - aliceryhl 6y ago
        Thanks for posting that link. I found the following issue because of it: https://github.com/rust-lang/rust/issues/80682 https://github.com/rust-lang/rust/issues/80682
  - aliceryhl 6y ago
    I mean obviously there are people who write incorrect unsafe code, but it is certainly something people take seriously.
- Blikkentrekker 6y ago
  Isn't every pointer `restrict` in Fortran which was often cited as why it still outperformed C in many cases for a very long time?
deleted 6y ago
[deleted]
pornel 6y ago
Rust's problem with aliasing in LLVM is caused exactly by limited usefulness of C's restrict. LLVM implements only coarse per-function aliasing information needed by C, and doesn't properly preserve fine-grained aliasing information that Rust can provide.
- zucker42 6y ago
  I thought the problem was there is simply a bug in the implementation because restrict isn't used frequently enough to have exposed the bug earlier.
- jcranmer 6y ago
  Note that Rust's issue was that LLVM is buggy with restrict (because it isn't exercised frequently). That said, there is a series of patches in-flight to get actual working full restrict support: https://reviews.llvm.org/D69542 https://reviews.llvm.org/D69542
roca 6y ago
"Just use 'restrict'" isn't as easy as it sounds. You need to only use 'restrict' where you are 100% sure pointers can't alias. Wherever you get this wrong you have introduced a subtle bug that a) only shows up in optimized code b) may or may not show up at all depending on compiler version and target architecture and c) only shows up when two pointers actually alias at runtime, which may be rare, and may be intermittent ... in other words these bugs will be hell to debug. So in fact in a large codebase it will be a lot of work to figure out where you can safely put 'restrict' and you will probably introduce some very nasty bugs. Most people aren't going to be willing to do this.
kouteiheika 6y ago
> I doubt there's any performance to be gained that way And how do you know this? Have you actually measured the difference? My CPU-heavy program (which takes ~30 seconds to run on a 32-core Threadripper) gains ~15% extra performance if I turn it on.
adrianN 6y ago
Sure, if you put the burden of proving correctness of restrict on the developer. That's like saying C programmers could just write memory safe code if they felt like this would help, so clearly memory safety is not important.

vvanders 6y ago

Have you ever used restrict in anger? I've done it when we really needed that performance for an inner loop(particle system). It can be a real bastard to keep the non-alias constraint held constant in a large, multi-person codebase and the error cases are really gnarly to chase down. Compare that to Rust which has this knowledge built in since it naturally falls out of the ownership model.

Gibbon1 6y ago
I agree with that, no aliasing in C is an ugly kludge that bitches about perfectly fine code that benefit benefit from it. And it's hard insure that it actually works in code that does. Worse the failure is completely silent.
- jart 6y ago
  Is there something special about the noalias keyword that it really brings out the most unprofessional pig language in developers? https://www.lysator.liu.se/c/dmr-on-noalias.html https://www.lysator.liu.se/c/dmr-on-noalias.html
cma 6y ago
When people use the unsafe keyword are they always taking into account aliasing? At least you can audit only those places though.
- zamalek 6y ago
  Yeah, `unsafe` is the developer signing a contract to uphold all the guarantees that safe rustc provided (at least from the perspective of the public interface, the invariants can be broken in private code). That's why Rust developers don't take kindly to unnecessary unsafe usage, because the audit surface area (and interaction complexity) increases.
  - millstone 6y ago
    But this is the crux. What sorts of aliasing are permitted in unsafe Rust? I think we kind of don't know; that's what the "stacked borrow" effort is trying to answer.
    - aliceryhl 6y ago
      We know pretty well for the vast majority of patterns whether it violates the aliasing rules or not. There may be some corner cases that are not yet decided on, but if you just consider those as UB for now, you are perfectly fine.
- slaymaker1907 6y ago
  Rust takes const with pointers very seriously. It is undefined behavior to mutate anything non-mut (pointer or reference) unless it is through an UnsafeCell. While you can break compiler guarantees through pointers in Rust, dereferencing this pointers must still obey the above guarantee (basically think of it as you need to go back to references to actually use the aliased pointers which would be undefined due to the aliasing). Therefore, the optimizer can always assume mutations don't alias. Even UnsafeCell isn't allowed to break the alias rules, it just provides flexibility going from immutable to mutable.
  - millstone 6y ago
    What you describe about 'const' is just about const correctness. That's important but different than aliasing. For example consider Slice::swap [1]. This does consider the possibility that the pointers alias, and correctly, because they might point at the same object. https://doc.rust-lang.org/src/core/slice/mod.rs.html#541-553 https://doc.rust-lang.org/src/core/slice/mod.rs.html#541-553
    - aliceryhl 6y ago
      Thanks for posting that link. I found the following issue because of it: https://github.com/rust-lang/rust/issues/80682 https://github.com/rust-lang/rust/issues/80682
- aliceryhl 6y ago
  I mean obviously there are people who write incorrect unsafe code, but it is certainly something people take seriously.
Blikkentrekker 6y ago
Isn't every pointer `restrict` in Fortran which was often cited as why it still outperformed C in many cases for a very long time?

deleted 6y ago

[deleted]

pornel 6y ago

Rust's problem with aliasing in LLVM is caused exactly by limited usefulness of C's restrict. LLVM implements only coarse per-function aliasing information needed by C, and doesn't properly preserve fine-grained aliasing information that Rust can provide.

zucker42 6y ago
I thought the problem was there is simply a bug in the implementation because restrict isn't used frequently enough to have exposed the bug earlier.
jcranmer 6y ago
Note that Rust's issue was that LLVM is buggy with restrict (because it isn't exercised frequently). That said, there is a series of patches in-flight to get actual working full restrict support: https://reviews.llvm.org/D69542 https://reviews.llvm.org/D69542

roca 6y ago

"Just use 'restrict'" isn't as easy as it sounds. You need to only use 'restrict' where you are 100% sure pointers can't alias. Wherever you get this wrong you have introduced a subtle bug that a) only shows up in optimized code b) may or may not show up at all depending on compiler version and target architecture and c) only shows up when two pointers actually alias at runtime, which may be rare, and may be intermittent ... in other words these bugs will be hell to debug. So in fact in a large codebase it will be a lot of work to figure out where you can safely put 'restrict' and you will probably introduce some very nasty bugs. Most people aren't going to be willing to do this.

kouteiheika 6y ago

> I doubt there's any performance to be gained that way And how do you know this? Have you actually measured the difference? My CPU-heavy program (which takes ~30 seconds to run on a 32-core Threadripper) gains ~15% extra performance if I turn it on.

adrianN 6y ago

Sure, if you put the burden of proving correctness of restrict on the developer. That's like saying C programmers could just write memory safe code if they felt like this would help, so clearly memory safety is not important.