Apparently the Rust compiler saw a 5% improvement (on average) when they enabled automatic aliasing information (they are now working with LLVM to get it back on).
Note that it is very program dependent, a friend got a 30% improvement on a very specialized numerical simulation.
Yeah, it's highly workload dependent. I've used restrict in anger to accelerate particle systems and we saw a significant speed boost.
Even a 5% speed increase is nothing to discount give that it's "free" once they have LLVM handling it correctly. I agree with the conclusion that if you have to manage the aliasing manually it's very limited in scenarios where you would want to deploy that given the failure modes of getting it wrong.
> Apparently the Rust compiler saw a 5% improvement (on average) when they enabled automatic aliasing information (they are now working with LLVM to get it back on).
For now, it should be part of the next release (1.54).
It was originally slated for 1.53, but then a new miscompilation was discovered during the 1.53 release cycle, so it stayed off.
1.54 landed just the other day, and I didn’t see any mention of noalias in the release notes. I’m curious to see if some of my microbenchmarks improve. And idea what’s going on with it? 1.55 maybe?
In Rust 1.54 the option known as `-Z mutable-noalias` is now on-by-default if you're using an LLVM version >= 12 (which includes the LLVM that ships with the official Rust distribution). I suspect it was overlooked in the release notes since the patch enabling it landed a few releases ago, and the patch was never reverted on nightly, only on beta/stable.
The downside is that it's totally out of your control. One small change to your program in a seemingly unrelated area, and suddenly your 5% or 30% improvement may vanish ...
In Rust, that's not true at all. The aliasing information flows out of the type system, which you control. If a reference is marked mutable, the compiler is free to treat it as unaliased, and an unrelated change elsewhere cannot change that.
It goes further- immutable/shared references get the same treatment as they will not change out from under you either.
The thing that disables it is interior mutability- types like `Mutex` or `Cell` that can be mutated through shared references fall back to something like C without TBAA.
`Mutex` (and `RwLock`) should not since they grant exclusive access, should they? As long as the aliasing information doesn't live across lockings, but that doesn't seem like it would happen: each locking would hand out a different guard, and thus a different reference the optimiser wouldn't see relating at all to the previous locking.
The upside is that it doesn't get a consultant calling a functions unaware of its restrict specification and triggering UB, much worse than losing those 5% or 30% improvements.
Note that it is very program dependent, a friend got a 30% improvement on a very specialized numerical simulation.