←back to thread

Tree Borrows

(plf.inf.ethz.ch)
572 points zdw | 2 comments | 09 Jul 25 14:40 UTC | HN request time: 0.493s | source
Show context
jcalvinowens ◴[09 Jul 25 18:21 UTC] No.44513250[source]▶
> On the one hand, compilers would like to exploit the strong guarantees of the type system—particularly those pertaining to aliasing of pointers—in order to unlock powerful intraprocedural optimizations.

How true is this really?

Torvalds has argued for a long time that strict aliasing rules in C are more trouble than they're worth, I find his arguments compelling. Here's one of many examples: https://lore.kernel.org/all/CAHk-=wgq1DvgNVoodk7JKc6BuU1m9Un... (the entire thread worth reading if you find this sort of thing interesting)

Is Rust somehow fundamentally different? Based on limited experience, it seems not (at least, when unsafe is involved...).

replies(11): >>44513333 #>>44513357 #>>44513452 #>>44513468 #>>44513936 #>>44514234 #>>44514867 #>>44514904 #>>44516742 #>>44516860 #>>44517860 #
1. ivanbakel ◴[09 Jul 25 20:04 UTC] No.44514234[source]▶
>How true is this really?

I’d be interested to see a more thorough analysis, but there is a simple way to gauge this - rip out all the parts of the compiler where aliasing information is propagated to LLVM, and see what happens to performance.

I found a claim that noalias contributes about 5% performance improvement in terms of runtimes[0], though the data is obviously very old.

https://github.com/rust-lang/rust/issues/54878#issuecomment-...

replies(1): >>44516399 #
2. kibwen ◴[10 Jul 25 01:38 UTC] No.44516399[source]▶
> I found a claim that noalias contributes about 5% performance improvement

Note that that comment is implying a range, from 0% improvement on some benchmarks to 5% improvement on others. It suggests that 5% is generally in the ballpark of the upper bound of what you should expect from putting noalias on mutable references, but that some specific cases could see better results.