Aliasing

Ono-Sendai 6 hours ago | parent | next [-]

When you have done enough C++ you don't need to fire up compiler explorer, you just use local variables to avoid aliasing pessimisations.

I also wrote about this a while ago: https://forwardscattering.org/post/51

	▲	dataflow 2 hours ago \| parent [-]
		I think this might not be a shortcoming of MSVC but rather a deliberate design decision. It seems likely that MSVC is failing to apply strict aliasing, but that it's deliberately avoiding it, probably for compatibility reasons with code that wasn't/isn't written to spec. And frankly it can be very onerous to write code that is 100% correct per the standard when dealing with e.g. memory-mapped files; I'm struggling to recall seeing a single case of this.

▲

turol 9 hours ago | parent | prev | next [-]

For a real world example of how this can affect code check out this commit I made in mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20...

▲

adev_ 9 hours ago | parent | prev | next [-]

Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays.

While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.

▲

uecker 3 hours ago | parent | next [-]

Is it? You just add "restrict" where needed?

https://godbolt.org/z/jva4shbjs

▲

adev_ 2 hours ago | parent [-]

> Is it? You just add "restrict" where needed?

Yes. That is the main solution and it is not a good one.

1- `restrict` need to be used carefully. Putting it everywhere in large codebase can lead to pretty tricky bugs if aliasing does occurs under the hood.

1- Restrict is not an official keyword in C++. C++ always has refused to standardize it because it plays terribly with almost any object model.

	▲	uecker 42 minutes ago \| parent [-]
		Regarding "restrict", I don't think one puts it everywhere, just for certain numerical loops which otherwise are not vectorized should be sufficient. FORTRAN seems even more dangerous to me. IMHO a better solution would be to have explicit notation for vectorized operations. Hopefully we will get this in C. Otherwise, I am very happy with C for numerics, especially with variably modified typs. For C++, yes, I agree.

▲

bregma 7 hours ago | parent | prev | next [-]

Aliasing can be a problem in Fortran too.

Decades ago I was a Fortran developer and encountered a very odd bug in which the wrong values were being calculated. After a lot of investigation I tracked it down to a subroutine call in which a hard-coded zero was being passed as an argument. It turned out that in the body of that subroutine the value 4 was being assigned to that parameter for some reason. The side effect was that the value of zero because 4 for the rest of the program execution because Fortran aliases all parameters since it passes by descriptor (or at least DEC FORTRAN IV did so on RSX/11). As you can imagine, hilarity ensued.

▲

pklausler 4 hours ago | parent [-]

How does this bug concern aliasing?

▲

Etheryte 2 hours ago | parent [-]

It's literally in the description? Because of aliasing, a variable that should've been zero became four.

	▲	pklausler an hour ago \| parent [-]
		It wasn't a variable.

▲

kryptiskt 5 hours ago | parent | prev [-]

Support for arrays without having to mess with pointers is pretty attractive for number crunchers too.

▲

andrepd 3 hours ago | parent | prev | next [-]

Thank you Rust for having aliasing guarantees on references!

▲

Bootvis 11 hours ago | parent | prev | next [-]

The whole series is excellent and as a non regular user of assembly I learned a ton.

▲

artemonster 11 hours ago | parent | prev [-]

I wonder how much potential optimisation there is if we entirely drop pointer nonsense.

▲

aw1621107 8 hours ago | parent | next [-]

Are you talking about dropping pointers as a programmer-facing programming language concept (in which case you might find Hylo and similar languages interesting), or dropping pointers from everything - programming languages, their implementations, compilers, etc. (in which case I'm not sure that's even possible)?

▲

artemonster 8 hours ago | parent [-]

Only the first one. Ofc under the hood they will stay, but I think its time to ditch random access model and pull fetching and concept of time closer to programmer

▲

uecker 3 hours ago | parent [-]

This is basically what many functional programming languages do. This always came with plausibly sounding claims that this allows so much better optimizations that this soon will surpass imperative programs in performance, but this never materialized (it still did not - even though Rust fans now adopted this claim, it still isn't quite true). Also control over explicit memory layout is still more important.

▲

aw1621107 an hour ago | parent [-]

Gah, can't believe I forgot about functional programming languages here :(

> even though Rust fans now adopted this claim

Did they? Rust's references seem pretty pointer-like to me on the scale of "has pointers" to "pointers have been entirely removed from the language".

(Obviously Rust has actual pointers as well, but since usefully using them requires unsafe I assume they're out of scope here)

	▲	uecker an hour ago \| parent [-]
		What I meant is that Rust has stricter aliasing rules which make some optimization possible without extra annotations, but this is balanced out by many other issues.

▲

newpavlov 5 hours ago | parent | prev [-]

For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust.

Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...