3 ms·

It is faster than C for numerical computing. One of the reasons is that aliasing is not allowed by the language, so the compiler can make some optimizations tha

It is faster than C for numerical computing. One of the reasons is that aliasing is not allowed by the language, so the compiler can make some optimizations that C compilers can't, because e.g. the C compiler cannot assume that two pointer arguments to a function do not point to the same memory location.

leephillips 5y ago
This was the historical reason for Fortran’s speed advantage over C. But more recent C compilers have a flag to turn off checking for aliasing, so you can write numerical C code with Fortran performance. It’s more verbose and annoying to write, though, because it lacks Fortran’s array syntax: loops for everything.
- zozbot234 5y ago
  Flags to turn off aliasing checks do exist in C compilers, but they result in 'slower', less optimized code. They're intended for the common case where types are reinterpreted in a way that isn't expressly allowed by the C/C++ standards, in which case the compiler can't use type information to infer that two pointers don't alias. FORTRAN can assume lack of aliasing in many other cases.
  - leephillips 5y ago
    Oh, interesting. Maybe I was thinking of the C `restrict` keyword, rather than a compiler flag. This is an instruction to the compiler, used in a pointer declaration, that there is promised to be no aliasing. It's supposed to allow C to get Fortran speeds in functions where it's used.
    - lmkg 5y ago
      It could allow C to close the gap in the future, but it's not there yet. Fortran is fundamentally and pervasively noalias, and its compilers have decades of experience operating under that assumption. C/C++ doesn't use it nearly as much, and as a result the parts of the compilers that use it aren't very mature. Rust is also pervasively noalias, but it's taken years for it to actually enable "noalias" on LLVM. Rust code uses that feature more than it's ever been used before, which keeps exposing codegen bugs that no one noticed before. Once those get flushed out, I still expect it will take a while for the resulting optimizations to reach the quality & maturity that Fortran has had.
      - zozbot234 5y ago
        That's exactly why it matters that LLVM is officially getting a Fortran frontend. This will make it possible to leverage these optimization strategies and bug fixes across languages and projects.
        leephillips 5y ago
        It also allows the existence of a Fortran REPL, something I never thought I would see: https://lfortran.org/ https://lfortran.org/
        tobmlt 5y ago
        This whole conversation has been very insightful. From the noalias = no panacea To the Fortran repl Thank you. This was inspiring. Maybe it’s time I learn me some llvm too. Cheers.

leephillips 5y ago

This was the historical reason for Fortran’s speed advantage over C. But more recent C compilers have a flag to turn off checking for aliasing, so you can write numerical C code with Fortran performance. It’s more verbose and annoying to write, though, because it lacks Fortran’s array syntax: loops for everything.

zozbot234 5y ago
Flags to turn off aliasing checks do exist in C compilers, but they result in 'slower', less optimized code. They're intended for the common case where types are reinterpreted in a way that isn't expressly allowed by the C/C++ standards, in which case the compiler can't use type information to infer that two pointers don't alias. FORTRAN can assume lack of aliasing in many other cases.
- leephillips 5y ago
  Oh, interesting. Maybe I was thinking of the C `restrict` keyword, rather than a compiler flag. This is an instruction to the compiler, used in a pointer declaration, that there is promised to be no aliasing. It's supposed to allow C to get Fortran speeds in functions where it's used.
  - lmkg 5y ago
    It could allow C to close the gap in the future, but it's not there yet. Fortran is fundamentally and pervasively noalias, and its compilers have decades of experience operating under that assumption. C/C++ doesn't use it nearly as much, and as a result the parts of the compilers that use it aren't very mature. Rust is also pervasively noalias, but it's taken years for it to actually enable "noalias" on LLVM. Rust code uses that feature more than it's ever been used before, which keeps exposing codegen bugs that no one noticed before. Once those get flushed out, I still expect it will take a while for the resulting optimizations to reach the quality & maturity that Fortran has had.
    - zozbot234 5y ago
      That's exactly why it matters that LLVM is officially getting a Fortran frontend. This will make it possible to leverage these optimization strategies and bug fixes across languages and projects.
      - leephillips 5y ago
        It also allows the existence of a Fortran REPL, something I never thought I would see: https://lfortran.org/ https://lfortran.org/
        tobmlt 5y ago
        This whole conversation has been very insightful. From the noalias = no panacea To the Fortran repl Thank you. This was inspiring. Maybe it’s time I learn me some llvm too. Cheers.