Live data from Hacker News

Flang: The Fortran frontend of LLVM [video]

fosdem.org

31–40 of 97 posts

Re: Flang: The Fortran frontend of LLVM [video]

#31
post #12

Earlier quoted context omitted.

I am not a compiler expert but I wonder if FORTRAN will lose its speed advantages it still supposedly has if it goes through LLVM.

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.

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.

Re: Flang: The Fortran frontend of LLVM [video]

#32
post #12

Earlier quoted context omitted.

I am not a compiler expert but I wonder if FORTRAN will lose its speed advantages it still supposedly has if it goes through LLVM.

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.

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

Re: Flang: The Fortran frontend of LLVM [video]

#33
post #24
post #12

Earlier quoted context omitted.

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.

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

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.

Re: Flang: The Fortran frontend of LLVM [video]

#34
post #28

I've never seen a fortram codebase in my life. Is it still alive? What advantages does it offer over C/C++?

Fortran has language-level support for things important for numerical scientific computing (complex numbers, multidimensional arrays, etc.), and it has had them since the beginning in the 1950-60s. The convenience is not really matched by C or C++, where similar features have been added much later by language extensions or 3rd party libraries, resulting to more complicated usage, fragmentation, and interoperability p…

Also numerical codes can be trickier to write than you think. Rounding errors and other treacheries of the floating point approximation to the 'real' numbers can eat you alive.

If you want to do common numeric operations they might be a FORTRAN code that is battle tested and performance tuned and it usually not hard to call from C, Java, Python or some other language.

Re: Flang: The Fortran frontend of LLVM [video]

#35
post #11

This reminded me of the Fortress language after a long time. It was a MODERN Fortran like language that Guy Steele and all were developing at Sun https://en.wikipedia.org/wiki/Fortress_(programming_language... It did not stand much of a chance once Oracle took over.

Fortress never got any real traction and was effectively dead well before Oracle purchased Sun.

Re: Flang: The Fortran frontend of LLVM [video]

#36
post #28

Earlier quoted context omitted.

Fortran has language-level support for things important for numerical scientific computing (complex numbers, multidimensional arrays, etc.), and it has had them since the beginning in the 1950-60s. The convenience is not really matched by C or C++, where similar features have been added much later by language extensions or 3rd party libraries, resulting to more complicated usage, fragmentation, and interoperability p…

Also numerical codes can be trickier to write than you think. Rounding errors and other treacheries of the floating point approximation to the 'real' numbers can eat you alive. If you want to do common numeric operations they might be a FORTRAN code that is battle tested and performance tuned and it usually not hard to call from C, Java, Python or some other language.

Fortran’s numerics model is actually somewhat weaker than C’s; if precise rounding behavior is your main concern C (while still not ideal) is a better option.

Re: Flang: The Fortran frontend of LLVM [video]

#38
post #2

On one hand this is a great news and as Fortran user pretty happy about it. On the other I’m a bit worried that once LLVM backend will take off for real, so much focus will concentrate on it, that other compilers (PGI, gfortran, Intel Fortran) development will finally stall or even get dropped and we will wake up in future where LLVM behemoth swallowed all the competition. This concern is not only limited to Fortran,…

Don’t worry; people said this about GCC (especially once Cygnus got going) and now llvm is challenging GCC. The existence of llvm has caused gcc to improve as well.

Gcc (well g++) is still my primary compiler though I do run my code through clang as well as llvm do catch different bugs. I can imagine llvm becoming my primary compiler at some point, but it will still be a few years.

Re: Flang: The Fortran frontend of LLVM [video]

#39
post #37

Mods, please add a [video] warning to the title.

Why should this be downvoted; it’s a standard thing to do on HN.

(Complaining about downvoting is not typically an acceptable thing on HN but I think this case is meta-respectable, though I appreciate the irony).

Re: Flang: The Fortran frontend of LLVM [video]

#40
post #2

On one hand this is a great news and as Fortran user pretty happy about it. On the other I’m a bit worried that once LLVM backend will take off for real, so much focus will concentrate on it, that other compilers (PGI, gfortran, Intel Fortran) development will finally stall or even get dropped and we will wake up in future where LLVM behemoth swallowed all the competition. This concern is not only limited to Fortran,…

I haven't seen that talk, but from a previous one, Flang is closely related to the PGI compiler, and F18 is to escape that.

I wouldn't miss the grief associated with ifort, which doesn't live up to the mythology. The salient feature of the PGI compiler is probably the offloading, and I assume that's Nvidia-specific, but I don't know how it compares with current, and upcoming, GCC support. The research computing world would be a better place if the money spent on proprietary compilers sponsored GCC improvements instead.

Post reply on HN