5 ms·

As far as I know, the main speed advantage is that Fortran supports arrays, which are known to not alias. C/C++ does not have alias-annotations built-in. Altho

As far as I know, the main speed advantage is that Fortran supports arrays, which are known to not alias. C/C++ does not have alias-annotations built-in. Although with template constructs like done in e.g. the Eigen library, alias-optimal code can be generated.

cygx 7y ago
C/C++ does not have alias-annotations built-in Restrict?
- stephencanon 7y ago
  Fortran defaults to no-alias, C and C++ default to may-alias. The annotations exist, but you have to apply them all over the place to get the benefit. It’s doable, but the Fortran model is less error-prone for many users.
  - gnufx 7y ago
    Actually, Fortran defines "storage association" rules, so code that doesn't obey them isn't conforming Fortran. I'm not sure about the error-prone, though, from long experience and users arguing with a compiler maintainer. One problem is lack of static checking.
    - stephencanon 7y ago
      Numeric code rarely (almost never, actually) requires aliasing, so defaulting to no-alias is less error prone for those users. If you’re writing an OS or runtime library, you want aliasing support and static checking, but that’s mostly out-of-scope for Fortran today.
      - gnufx 7y ago
        The Fortran standard just doesn't talk about "aliasing" (in that context), and "defaulting" suggests you can turn off the storage association rules somehow. I maintain from long research computing experience (at least back to the days of Alliant) that the rules are highly error prone in practice for users, who frequently deny they even exist, and blame the compiler bugs. (I'm surprised if that's not the case more generally.) I'm not saying they shouldn't exist, or that code needs to contravene them.
        stephencanon 7y ago
        Yeah, I'm using the C nomenclature ("aliasing" vs "association") because HN commenters are broadly unfamiliar with Fortran. What I mean by "default" is that if I declare a function with two array arguments in Fortran, with the simplest possible syntax, the compiler assumes that they do not alias (are not associated). By contrast, if I declare a function with two pointer arguments in C, with the simplest possible syntax, the compiler assumes that they may alias (are associated in some unspecified manner). The C semantics are certainly safer, but they lead to lots of "Fortran is faster than C" blog posts by people who either don't know about or simply don't want to use the annotations.
dsqrt 7y ago
C has the "restrict" keyword to indicate that no aliasing should occur.
- gilnaa 7y ago
  But is mostly unused and mostly irrelevant
galangalalgol 7y ago
There are bugs in llvm mostly found by rust that are related to this. This will be another source of pressure to fix these bugs, which is good.
- hsivonen 7y ago
  My main hope for flang is that it motivates LLVM to fix the Rust-relevant non-aliasing bugs. However, is it actually known that flang/f18 emits IR with the same patterns that exposed the Rust-relevant LLVM bugs?
PudgePacket 7y ago
Other posters mentioned "restrict". Rust is able to basically use "restrict" on steroids because of how much more info has, so much so that it's brought up bugs in LLVM that are not fixed yet. https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878
Gibbon1 7y ago
I just thought of a stupid question. If gcc and LLVM both support fortran how actually hard would it be really to add real arrays to C? At least as an option? AKA add an option --fortran_arrays.
- pjmlp 7y ago
  It has been done multiple times in safe C dialects, the problem is the community, not technical.

cygx 7y ago

C/C++ does not have alias-annotations built-in Restrict?

stephencanon 7y ago
Fortran defaults to no-alias, C and C++ default to may-alias. The annotations exist, but you have to apply them all over the place to get the benefit. It’s doable, but the Fortran model is less error-prone for many users.
- gnufx 7y ago
  Actually, Fortran defines "storage association" rules, so code that doesn't obey them isn't conforming Fortran. I'm not sure about the error-prone, though, from long experience and users arguing with a compiler maintainer. One problem is lack of static checking.
  - stephencanon 7y ago
    Numeric code rarely (almost never, actually) requires aliasing, so defaulting to no-alias is less error prone for those users. If you’re writing an OS or runtime library, you want aliasing support and static checking, but that’s mostly out-of-scope for Fortran today.
    - gnufx 7y ago
      The Fortran standard just doesn't talk about "aliasing" (in that context), and "defaulting" suggests you can turn off the storage association rules somehow. I maintain from long research computing experience (at least back to the days of Alliant) that the rules are highly error prone in practice for users, who frequently deny they even exist, and blame the compiler bugs. (I'm surprised if that's not the case more generally.) I'm not saying they shouldn't exist, or that code needs to contravene them.
      - stephencanon 7y ago
        Yeah, I'm using the C nomenclature ("aliasing" vs "association") because HN commenters are broadly unfamiliar with Fortran. What I mean by "default" is that if I declare a function with two array arguments in Fortran, with the simplest possible syntax, the compiler assumes that they do not alias (are not associated). By contrast, if I declare a function with two pointer arguments in C, with the simplest possible syntax, the compiler assumes that they may alias (are associated in some unspecified manner). The C semantics are certainly safer, but they lead to lots of "Fortran is faster than C" blog posts by people who either don't know about or simply don't want to use the annotations.

dsqrt 7y ago

C has the "restrict" keyword to indicate that no aliasing should occur.

gilnaa 7y ago
But is mostly unused and mostly irrelevant

galangalalgol 7y ago

There are bugs in llvm mostly found by rust that are related to this. This will be another source of pressure to fix these bugs, which is good.

hsivonen 7y ago
My main hope for flang is that it motivates LLVM to fix the Rust-relevant non-aliasing bugs. However, is it actually known that flang/f18 emits IR with the same patterns that exposed the Rust-relevant LLVM bugs?

PudgePacket 7y ago

Other posters mentioned "restrict". Rust is able to basically use "restrict" on steroids because of how much more info has, so much so that it's brought up bugs in LLVM that are not fixed yet. https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878

Gibbon1 7y ago

I just thought of a stupid question. If gcc and LLVM both support fortran how actually hard would it be really to add real arrays to C? At least as an option? AKA add an option --fortran_arrays.

pjmlp 7y ago
It has been done multiple times in safe C dialects, the problem is the community, not technical.