4 ms·

Fortran as a language had some advantages over C for high-performance numeric code (eg more restrictive aliasing rules or stack-allocated variable-length arrays

by cygx 7y ago

Fortran as a language had some advantages over C for high-performance numeric code (eg more restrictive aliasing rules or stack-allocated variable-length arrays). C99 addressed this.

pjmlp 7y ago
C99 kind of addressed it, unless one manually takes the effort to properly place restrict in the correct places, and not mistakenly misuse it (possibly triggering UB), it won't match what optimizing Fortran compilers are capable of without any additional effort from the programmer.
- 1996 7y ago
  Thanks. Your answer and ecshafer point me to start evaluating Fortran.
- cygx 7y ago
  But note that that as far as I'm aware, Fortran compilers will happily miscompile code that breaks the aliasing assumptions as well. No matter which language you use, it's the responsibility of the programmer to not break these invariants, the main difference being that Fortran doesn't force you to type out `restrict` first.
  - pjmlp 7y ago
    In Fortran there aren't aliasing assumptions as in C, given that they are forbidden by the type system.
    - cygx 7y ago
      It's forbidden by the language standard, hence compilers assume no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code. In the words of the g77 manual: > Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable. > [...] > Unfortunately, there is no way to find all possible cases of violations of the prohibitions against aliasing in Fortran code. Static analysis is certainly imperfect, as is run-time analysis, since neither can catch all violations. (Static analysis can catch all likely violations, and some that might never actually happen, while run-time analysis can catch only those violations that actually happen during a particular run. Neither approach can cope with programs mixing Fortran code with routines written in other languages, however.) Like in C, it will result in undefined behaviour (though the Fortran spec doesn't use the term).
      - pjmlp 7y ago
        Fortran 77, when the latest version is Fortran 2018? Nevertheless, that is like describing C semantics with something that is only possible in GNU C. Naturally if one goes outside what the standard allows, everything goes.
        cygx 7y ago
        Fortran 77, when the latest version is Fortran 2018? It was the first relevant search result. Feel free to look for more recent resources on the topic, eg https://www.sciencedirect.com/science/article/pii/S1571066104803967 https://www.sciencedirect.com/science/article/pii/S157106610... (still a bit dated). Naturally if one goes outside what the standard allows, everything goes. Which makes the Fortran situation essentially the same as the C one once you've typed out `restrict`.
        pjmlp 7y ago
        Not really, because the standard is what defines the language, just because GNU Fortran does non conforming stuff it doesn't mean that for example PGI Fortran would do the same non conforming behavior. By the same measure I can assert that C++ is a memory safe language given that Visual C++ enables bounds checking and iterator invalidation in the standard library by default.
        cygx 7y ago
        The C language standard makes certain guarantees, such as no out-of-bounds array access, or no modification of memory accessed through a restrict-qualified expression by other means. If such things happen during program execution, the program does not conform to the standard, and its runtime behaviour becomes undefined. This is exactly the same situation you have with Fortran, which makes certain guarantees about, say, the aliasing of function arguments. If all such cases could be detected ahead of time, it would be impossible for programmers to write non-conforming programs. This is not possible. I repeat, there is no essential difference between the Fortran and C situation. The best one could argue is that given that the Fortran guarantees are universal (instead of limited to restrict-qualified pointers), a Fortran programmer is less likely to write an incorrect program, but that's it.

by cygx 7y ago

Fortran as a language had some advantages over C for high-performance numeric code (eg more restrictive aliasing rules or stack-allocated variable-length arrays). C99 addressed this.

pjmlp 7y ago

C99 kind of addressed it, unless one manually takes the effort to properly place restrict in the correct places, and not mistakenly misuse it (possibly triggering UB), it won't match what optimizing Fortran compilers are capable of without any additional effort from the programmer.

1996 7y ago
Thanks. Your answer and ecshafer point me to start evaluating Fortran.
cygx 7y ago
But note that that as far as I'm aware, Fortran compilers will happily miscompile code that breaks the aliasing assumptions as well. No matter which language you use, it's the responsibility of the programmer to not break these invariants, the main difference being that Fortran doesn't force you to type out `restrict` first.
- pjmlp 7y ago
  In Fortran there aren't aliasing assumptions as in C, given that they are forbidden by the type system.
  - cygx 7y ago
    It's forbidden by the language standard, hence compilers assume no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code. In the words of the g77 manual: > Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable. > [...] > Unfortunately, there is no way to find all possible cases of violations of the prohibitions against aliasing in Fortran code. Static analysis is certainly imperfect, as is run-time analysis, since neither can catch all violations. (Static analysis can catch all likely violations, and some that might never actually happen, while run-time analysis can catch only those violations that actually happen during a particular run. Neither approach can cope with programs mixing Fortran code with routines written in other languages, however.) Like in C, it will result in undefined behaviour (though the Fortran spec doesn't use the term).
    - pjmlp 7y ago
      Fortran 77, when the latest version is Fortran 2018? Nevertheless, that is like describing C semantics with something that is only possible in GNU C. Naturally if one goes outside what the standard allows, everything goes.
      - cygx 7y ago
        Fortran 77, when the latest version is Fortran 2018? It was the first relevant search result. Feel free to look for more recent resources on the topic, eg https://www.sciencedirect.com/science/article/pii/S1571066104803967 https://www.sciencedirect.com/science/article/pii/S157106610... (still a bit dated). Naturally if one goes outside what the standard allows, everything goes. Which makes the Fortran situation essentially the same as the C one once you've typed out `restrict`.
        pjmlp 7y ago
        Not really, because the standard is what defines the language, just because GNU Fortran does non conforming stuff it doesn't mean that for example PGI Fortran would do the same non conforming behavior. By the same measure I can assert that C++ is a memory safe language given that Visual C++ enables bounds checking and iterator invalidation in the standard library by default.
        cygx 7y ago
        The C language standard makes certain guarantees, such as no out-of-bounds array access, or no modification of memory accessed through a restrict-qualified expression by other means. If such things happen during program execution, the program does not conform to the standard, and its runtime behaviour becomes undefined. This is exactly the same situation you have with Fortran, which makes certain guarantees about, say, the aliasing of function arguments. If all such cases could be detected ahead of time, it would be impossible for programmers to write non-conforming programs. This is not possible. I repeat, there is no essential difference between the Fortran and C situation. The best one could argue is that given that the Fortran guarantees are universal (instead of limited to restrict-qualified pointers), a Fortran programmer is less likely to write an incorrect program, but that's it.