Hacker News Reader

Comment by greenshackle2 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

It also allows the existence of a Fortran REPL, something I never thought I would see: https://lfortran.org/

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.

Reply on news.ycombinator.com