6 ms·

>This restriction is central to Rust’s safety guarantees, but C# doesn’t need it. The reason is that Rust has to account for the possibility that a reference ma

>This restriction is central to Rust’s safety guarantees, but C# doesn’t need it. The reason is that Rust has to account for the possibility that a reference may be invalidated at any time. That’s not why though. There’s lots of reasons for Rusts safety model, such as allowing for vastly faster code because aliasing can’t happen unless both references are read only, in which case it doesn’t matter. There is lot to Rusts borrow rules that this article misses. It’s like the article earlier today that was, essentially, “I don’t understand Rust and it would be better if it was Haskell”.

fulafel 2y ago
Is there some benchmarking work that has quantified this speedup from aliasing guarantees or is this more of a sufficiently smart compiler[1] thing? [1] https://kidneybone.com/c2/wiki/SufficientlySmartCompiler https://kidneybone.com/c2/wiki/SufficientlySmartCompiler
- DonaldPShimoda 2y ago
  The Sufficiently Smart Compiler is a hypothetical argument used in advocating for a programming language whose naive implementations might tend towards inefficient designs, whereas the aliasing argument is not itself hypothetical but it may not be backed by data. That's a different thing altogether. Whether the aliasing argument holds water does not affect whether it was used as justification for Rust's design.
- vlovich123 2y ago
  Of course: https://github.com/rust-lang/rust/issues/54878#issuecomment-767151730 https://github.com/rust-lang/rust/issues/54878#issuecomment-... TLDR: 0-5% faster with noalias optimizations on. You can always try running some benchmarks by building code with -Zmutable-noalias=no.
  - fulafel 2y ago
    Thanks. If anyone has a link to results handy I'd be intersted. In particular a lot changes can be said to be 0-5% where the average is very close to 0...
- deleted 2y ago
  [deleted]
physicsguy 2y ago
> aliasing can’t happen unless both references are read only Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword though obviously it's a programmer guarantee there and is less safe, since if the user of the function does pass the same memory ref offset for e.g. the optimisation is not safe.
- orangeboats 2y ago
  The restrict keyword is very seldomly used in C programs. You could probably remove it and still be able to compile the majority of C programs. (Otherwise, the Rust project wouldn't have encountered all the bugs related to aliasing analysis in LLVM.)
  - kazinator 2y ago
    The ISO C standard uses the restrict qualifier on some standard library function declarations in such a way that it does nothing.
  - physicsguy 2y ago
    It's not used much in a sense that it's applied to very few functions, but it is well known and widely used in limited circumstances. The bugs in LLVM (and GCC) are basically because Rust is using aliasing much more widely than it ever has been in most C programs. Take for e.g. this: void add(double *A, double *B, double *C, int N) { for(int i = 0; i < N; i++) { C[i] = A[i] + B[i]; } } You generally wouldn't find many C developers sprinkling restrict in on functions like this, since that function could be useful to someone using add on two overlapping arrays. On the other hand, someone writing a ODE solver in a scientific code might write a function like this, where it would never make sense for the memory locations to overlap: void RHS(double* restrict x, double* restrict xdot, int N, double dt) { for(int i = 0; i < N; i++) { xdot[i] = -x[i]/dt; } } In those sorts of circumstances, it's one of the first performance optimisations you might reach for in your C/C++ toolkit, before starting to look at for e.g. parallelism. It's been in every simulation or mathematical code base I've worked on in 10+ years at various different academic institutions and industry companies.

fulafel 2y ago

Is there some benchmarking work that has quantified this speedup from aliasing guarantees or is this more of a sufficiently smart compiler[1] thing? [1] https://kidneybone.com/c2/wiki/SufficientlySmartCompiler https://kidneybone.com/c2/wiki/SufficientlySmartCompiler

DonaldPShimoda 2y ago
The Sufficiently Smart Compiler is a hypothetical argument used in advocating for a programming language whose naive implementations might tend towards inefficient designs, whereas the aliasing argument is not itself hypothetical but it may not be backed by data. That's a different thing altogether. Whether the aliasing argument holds water does not affect whether it was used as justification for Rust's design.
vlovich123 2y ago
Of course: https://github.com/rust-lang/rust/issues/54878#issuecomment-767151730 https://github.com/rust-lang/rust/issues/54878#issuecomment-... TLDR: 0-5% faster with noalias optimizations on. You can always try running some benchmarks by building code with -Zmutable-noalias=no.
- fulafel 2y ago
  Thanks. If anyone has a link to results handy I'd be intersted. In particular a lot changes can be said to be 0-5% where the average is very close to 0...
deleted 2y ago
[deleted]

physicsguy 2y ago

> aliasing can’t happen unless both references are read only Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword though obviously it's a programmer guarantee there and is less safe, since if the user of the function does pass the same memory ref offset for e.g. the optimisation is not safe.

orangeboats 2y ago
The restrict keyword is very seldomly used in C programs. You could probably remove it and still be able to compile the majority of C programs. (Otherwise, the Rust project wouldn't have encountered all the bugs related to aliasing analysis in LLVM.)
- kazinator 2y ago
  The ISO C standard uses the restrict qualifier on some standard library function declarations in such a way that it does nothing.
- physicsguy 2y ago
  It's not used much in a sense that it's applied to very few functions, but it is well known and widely used in limited circumstances. The bugs in LLVM (and GCC) are basically because Rust is using aliasing much more widely than it ever has been in most C programs. Take for e.g. this: void add(double *A, double *B, double *C, int N) { for(int i = 0; i < N; i++) { C[i] = A[i] + B[i]; } } You generally wouldn't find many C developers sprinkling restrict in on functions like this, since that function could be useful to someone using add on two overlapping arrays. On the other hand, someone writing a ODE solver in a scientific code might write a function like this, where it would never make sense for the memory locations to overlap: void RHS(double* restrict x, double* restrict xdot, int N, double dt) { for(int i = 0; i < N; i++) { xdot[i] = -x[i]/dt; } } In those sorts of circumstances, it's one of the first performance optimisations you might reach for in your C/C++ toolkit, before starting to look at for e.g. parallelism. It's been in every simulation or mathematical code base I've worked on in 10+ years at various different academic institutions and industry companies.