On Wed, Mar 27, 2024 at 01:45:46PM -0700, Linus Torvalds wrote: > On Wed, 27 Mar 2024 at 12:41, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > > _But_: the lack of any aliasing guarantees means that writing through > > any pointer can invalidate practically anything, and this is a real > > problem. > > It's actually much less of a problem than you make it out to be. > > A lot of common aliasing information is statically visible (offsets > off the same struct pointer etc). > > The big problems tend to be > > (a) old in-order hardware that really wants the compiler to schedule > memory operations > > (b) vectorization and HPC Yeah, I was being a bit dramatic given the current state of the world - OOO machines _mostly_ do a reasonable job of hiding the negative effects of this (although not always, when memory barriers are involved). But I think this is going to become important again in the future, for a couple reasons. On the hardware end, the Mill guys were pointing out years ago that register renaming is a big power bottleneck in modern processors; the actual functional units consume practically nothing compared to just moving data around. They never built anything, but there's at least one new startup I know of that's continuing their work. Yes, VLIW has been a bust repeatedly, but as we keep going wider and wider (because what else are we going to do?) I think it's going to happen eventually. On the compiler side, I'm taking the long view: it's really not just about a few reloads here and there, it's that you fundamentally can't do that much with code that's mutating arbitrary state; analysis that optimizations depend on is impossible. In the compiler you really want to be working with code that's pure functional - then all your optimizations are just algebra. And internally, compilers do this as much as they can (SSA form...), but - unrestricted pointers really put a limit on what they can do. The beautiful thing about Rust to me is that we finally might have a path out of this; the rules of Rust references constrain mutability in such a way that's almost as good as being purely functional, yet it's something we can actually do systems programming with. I think this is going to lead to substantially better code optimization in the future, and based on a much more sound model that means we won't constantly be fighting with compiler people because they're doing shady shit and breaking previously working code. Based on my experiences with writing iterator heavy code in both C and Rust, I think it already is.
