Aliasing

#1

Post by ibobev » Tue, Dec 16, 2025, 10:13 AM UTC

Aliasing
xania.org

Re: Aliasing

#2

Post by Bootvis » Mon, Dec 22, 2025, 6:54 AM UTC

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

Re: Aliasing

#3

Post by artemonster » Mon, Dec 22, 2025, 7:51 AM UTC

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

Re: Aliasing

#4

Post by adev_ » Mon, Dec 22, 2025, 9:37 AM UTC

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.

Re: Aliasing

#5

Post by turol » Mon, Dec 22, 2025, 9:41 AM UTC

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

Re: Aliasing

#6

Post by aw1621107 » Mon, Dec 22, 2025, 10:06 AM UTC

artemonster wrote: post #3

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

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)?

Re: Aliasing

#7

Post by artemonster » Mon, Dec 22, 2025, 10:19 AM UTC

aw1621107 wrote: post #6

artemonster wrote: post #3

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

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)?

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

Re: Aliasing

#8

Post by bregma » Mon, Dec 22, 2025, 11:23 AM UTC

adev_ wrote: post #4

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.

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.

Re: Aliasing

#9

Post by Ono-Sendai » Mon, Dec 22, 2025, 12:15 PM UTC

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

Re: Aliasing

#10

Post by newpavlov » Mon, Dec 22, 2025, 12:58 PM UTC

artemonster wrote: post #3

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

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