Hacker News Reader

Comment by stabbles | Hacker News Reader

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.

View on HN

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.

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.

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

When people use the unsafe keyword are they always taking into account aliasing?

At least you can audit only those places though.

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.

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.

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.

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.

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

Thanks for posting that link. I found the following issue because of it: https://github.com/rust-lang/rust/issues/80682

I mean obviously there are people who write incorrect unsafe code, but it is certainly something people take seriously.

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?

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

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.

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.

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

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

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.

Reply on news.ycombinator.com