Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flang: The Fortran frontend of LLVM [video]

fosdem.org

Post reply on HN
Print view View original

81–90 of 97 posts

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

#81

Post by Gibbon1 »

Fronzie wrote: post #12
Ididntdothis wrote: post #9

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.

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.

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

#82

Post by gnufx »

debugbreak42 wrote: post #51
gnufx wrote: post #41

Earlier quoted context omitted.

Is it really that simple (I don't know how decoupled it is.) ? There have been multiple Fortran front ends over the years, albeit not for F2018.

Not quite. Every compiler typically comes with its own runtime library (RTL). Thus, an output of one frontend is likely to have RTL calls specific to that compiler. For example, gfortran makes calls to its RTL, which is not the same RTL used by Intel compiler.

I'm well aware of Fortran runtimes. The question was getting at whether the front end is completely independent of the middle(?) end.

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

#83

Post by celrod »

stephencanon wrote: post #78
celrod wrote: post #55

Earlier quoted context omitted.

I've been working on LoopVectorization in Julia, and benchmarking against a few compilers. Intel's compilers are far ahead of GCC and LLVM in vectorizing loops. LLVM (even with Polly) fairs worst in my benchmarks, so it does not look like a future where Intel is obsolete is on the horizon yet. However, I am excited for Flang and its FIR MLIR-dialect. I haven't benchmarked MLIR-optimized code at all. I'm sure that wil…

Note that a lot of Intel’s advantage in SIMD, historically, came from optimization modes that simply (unsafely) assume that there are no dependencies that would block vectorization (instead of doing the conservative analysis like GCC and Clang). It makes for impressive benchmarks, but is borderline-unusable in much real code. Intel’s compiler team has actually suggested some patches adding the same mode to LLVM, thou…

Interesting. Would this be safer in a language like Fortran, where (without aliasing between separate arrays), loop dependencies should be more obvious?

I think it'd be nice to be able to activate this mode through pragmas.

Does "#pragma omp simd" result in more aggressive use of blocking?

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

#84

Post by gnufx »

stephencanon wrote: post #65
gnufx wrote: post #47

Earlier quoted context omitted.

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.

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.

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.

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

#85

Post by gnufx »

celrod wrote: post #55
cultus wrote: post #14

Earlier quoted context omitted.

I really doubt Intel Fortran will stall. ifort is pretty big business for Intel and the HPC space. It's probably one area where LLVM's advantages don't really matter.

I've been working on LoopVectorization in Julia, and benchmarking against a few compilers. Intel's compilers are far ahead of GCC and LLVM in vectorizing loops. LLVM (even with Polly) fairs worst in my benchmarks, so it does not look like a future where Intel is obsolete is on the horizon yet. However, I am excited for Flang and its FIR MLIR-dialect. I haven't benchmarked MLIR-optimized code at all. I'm sure that wil…

There will be cases for which it's not so, but every time recently that I can remember someone saying ifort/icc vectorizes some numerical code profitably, and gfortran doesn't, and I had the code, I got GCC vectorizing it with equivalent flags. ifort defaults to incorrect behaviour for floating point (something like gcc -ffast-math). [Edit: As I now see it says in a sibling.]

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

#86

Post by gnufx »

noobermin wrote: post #74
celrod wrote: post #55

Earlier quoted context omitted.

I've been working on LoopVectorization in Julia, and benchmarking against a few compilers. Intel's compilers are far ahead of GCC and LLVM in vectorizing loops. LLVM (even with Polly) fairs worst in my benchmarks, so it does not look like a future where Intel is obsolete is on the horizon yet. However, I am excited for Flang and its FIR MLIR-dialect. I haven't benchmarked MLIR-optimized code at all. I'm sure that wil…

I'd say it's more than merely far ahead. When it's your hardware and you've been doing HPC optimization for decades, you are leagues ahead.

This "leagues ahead" is simply not true experimentally. I ran the Polyhedron benchmarks on SKX with profile-guided optimization. Pre-release gfortran 10 was (insignificantly) faster on the bottom line than beta ifort (from oneapi). That was reversed for gfortran 8 v. ifort 18.

It's also not true that HPC performance is generally dominated by code generation rather than libraries and communication costs, but obviously mileage varies.

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

#87

Post by gnufx »

stephencanon wrote: post #36
PaulHoule wrote: post #34

Earlier quoted context omitted.

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.

For those of us not expert on the standards, could you explain in what way Fortran is weaker, and its rounding control deficient?

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

#88

Post by riffraff »

gumby wrote: post #79
pjmlp wrote: post #67

Earlier quoted context omitted.

I am predicting that non-copyleft licenses will replace all uses of copyleft licenses, and everyone will get basic functionality in open source with juice bits only avaiable in the commercial versions, just like in the old days before of the rise of GPL. The evolution of BSD's adoption by commercial entities shows the way.

I hope you're wrong. The strength of Linux, Apache, and AGPL points the other way. It's almost impossible to get a chip from the likes of Rockchip or Mediatek without a Linux and/or Android bistro attached. GPL-style licenses on IoT systems may be an important part of the only way to avoid an apocalypse of compromised crapware IoT devices. The more serious problem is the weaponization of open source by the big actors…

Is AGPL strong? I can't come up with many examples off the top of my head as much as I can think of, say, MIT/GPL/LGPL.

I mean, it has been around much less time but does not seem to be an especially common choice.

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

#89

Post by mkj »

stephencanon wrote: post #78
celrod wrote: post #55

Earlier quoted context omitted.

I've been working on LoopVectorization in Julia, and benchmarking against a few compilers. Intel's compilers are far ahead of GCC and LLVM in vectorizing loops. LLVM (even with Polly) fairs worst in my benchmarks, so it does not look like a future where Intel is obsolete is on the horizon yet. However, I am excited for Flang and its FIR MLIR-dialect. I haven't benchmarked MLIR-optimized code at all. I'm sure that wil…

Note that a lot of Intel’s advantage in SIMD, historically, came from optimization modes that simply (unsafely) assume that there are no dependencies that would block vectorization (instead of doing the conservative analysis like GCC and Clang). It makes for impressive benchmarks, but is borderline-unusable in much real code. Intel’s compiler team has actually suggested some patches adding the same mode to LLVM, thou…

My experience in optimising c++ and Fortran with Intel compiler 16 is that it is safe regarding dependencies. Often #pragma ivdep is required to vectorise loops it can't accept otherwise.

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

#90

Post by riffraff »

stephencanon wrote: post #35
srean wrote: 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.

IIRC the point of fortress was to win DARPA's high productivity computing challenge, having failed at that it just remained a random research language.

Which is a pity, because it had some very interesting ideas, imvho.

Post reply on HN