4 ms·

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 m

by adev_ 10mo ago

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.

bregma 10mo ago
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 10mo ago
  How does this bug concern aliasing?
  - Etheryte 10mo ago
    It's literally in the description? Because of aliasing, a variable that should've been zero became four.
    - pklausler 10mo ago
      It wasn't a variable.
      - Etheryte 10mo ago
        It wasn't intended to be a variable, but it did become one. Its value varied, it's in the name.
        pklausler 10mo ago
        But this is just Fortran's call-by-reference in action. It's not aliasing.
  - mrspuratic 10mo ago
    In old school FORTRAN (I only recall WATFOR/F77, my uni's computers were quite ancient) subroutine (aka "subprogram") parameters are call-by-reference. If you passed a literal constant it would be treated as a variable in order to be aliased/passed by reference. Due to "constant pooling", modifications to a variable that aliased a constant could then propagate throughout the rest of the program where that constant[sic] was used. "Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html https://www.ibiblio.org/pub/languages/fortran/ch1-8.html
kryptiskt 10mo ago
Support for arrays without having to mess with pointers is pretty attractive for number crunchers too.
uecker 10mo ago
Is it? You just add "restrict" where needed? https://godbolt.org/z/jva4shbjs https://godbolt.org/z/jva4shbjs
- adev_ 10mo ago
  > 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 10mo ago
    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.

by adev_ 10mo ago

bregma 10mo ago

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 10mo ago
How does this bug concern aliasing?
- Etheryte 10mo ago
  It's literally in the description? Because of aliasing, a variable that should've been zero became four.
  - pklausler 10mo ago
    It wasn't a variable.
    - Etheryte 10mo ago
      It wasn't intended to be a variable, but it did become one. Its value varied, it's in the name.
      - pklausler 10mo ago
        But this is just Fortran's call-by-reference in action. It's not aliasing.
- mrspuratic 10mo ago
  In old school FORTRAN (I only recall WATFOR/F77, my uni's computers were quite ancient) subroutine (aka "subprogram") parameters are call-by-reference. If you passed a literal constant it would be treated as a variable in order to be aliased/passed by reference. Due to "constant pooling", modifications to a variable that aliased a constant could then propagate throughout the rest of the program where that constant[sic] was used. "Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html https://www.ibiblio.org/pub/languages/fortran/ch1-8.html

kryptiskt 10mo ago

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

uecker 10mo ago

Is it? You just add "restrict" where needed? https://godbolt.org/z/jva4shbjs https://godbolt.org/z/jva4shbjs

adev_ 10mo ago
> 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 10mo ago
  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.