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

71–80 of 97 posts

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

#71

Post by chrisseaton »

throwaway894345 wrote: post #70
kryptiskt wrote: post #5

Earlier quoted context omitted.

I'm hoping for Cranelift ( https://github.com/bytecodealliance/cranelift ) to deliver a more JIT-friendly alternative to LLVM (Though it can do AOT compilation too). Another very interesting project, even if it is slightly intimidating in scope, is GraalVM ( https://www.graalvm.org ).

I browsed their github and their linked docs, and it wasn't obvious to me what benefit cranelift has over LLVM. There was one section on implementation differences, but I'm not familiar/smart enough to infer from that what use cases cranelift enables.

I believe compilation speed is much better, for one immediate practical benefit. I think there are others but not sure. Many many people have tried to use LLVM as a JIT and either given up, or had to add significant infrastructure, such as additional IRs, on top to make it work.

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

#72

Post by noobermin »

tikej wrote: 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,…

>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.

It is likely it will take years if not decades for the llvm based fortran compiler to match the optimization ability of compilers on hpc systems. I also will clarify that the previous statement was an understatement. gfortran is one thing, PGI or Intel compilers won't stall or fall out of use.

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

#73

Post by mitchty »

jcranmer wrote: post #58
mitchty wrote: post #30

Earlier quoted context omitted.

If that really were the case, why did Chris Lattner try to give clang/llvm over to the FSF and merge it into gcc? Which failed only apparently due to Stallman not noticing the emails. After which Apple started pushing clang/llvm as in a way, they were shunned by gcc. The rest of your comment is... way too political towards gpl.

Chris Lattner suggested it back when gcc was first working on LTO, and clang didn't exist. 2004 or 2005-ish, IIRC. Back then, he was still working at UIUC. Apple pushed clang as a competitor to gcc much later, closer to 2010-ish.

I'm curious then how the email from Chris in 2005 comes from his apple.com email address?

https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html

Doesn't seem to add up with your proposed timeline. Care to explain?

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

#74

Post by noobermin »

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…

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.

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

#75

Post by throwaway894345 »

chrisseaton wrote: post #71
throwaway894345 wrote: post #70

Earlier quoted context omitted.

I browsed their github and their linked docs, and it wasn't obvious to me what benefit cranelift has over LLVM. There was one section on implementation differences, but I'm not familiar/smart enough to infer from that what use cases cranelift enables.

I believe compilation speed is much better, for one immediate practical benefit. I think there are others but not sure. Many many people have tried to use LLVM as a JIT and either given up, or had to add significant infrastructure, such as additional IRs, on top to make it work.

So are those the motivations/design-goals or just nice properties? In particular, is JIT/fast-compilation speed incidental to the relative youth of the project? I.e., presumably fewer optimizations vs LLVM allows the compiler to be faster?

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

#76

Post by chrisseaton »

throwaway894345 wrote: post #75
chrisseaton wrote: post #71

Earlier quoted context omitted.

I believe compilation speed is much better, for one immediate practical benefit. I think there are others but not sure. Many many people have tried to use LLVM as a JIT and either given up, or had to add significant infrastructure, such as additional IRs, on top to make it work.

So are those the motivations/design-goals or just nice properties? In particular, is JIT/fast-compilation speed incidental to the relative youth of the project? I.e., presumably fewer optimizations vs LLVM allows the compiler to be faster?

It's design-goals and tradeoffs. It was a light JIT compiler first, and has been designed that way, while LLVM is an heavy AOT compiler and was designed that way.

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

#77

Post by stephencanon »

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.

There are no great secrets to the HW or vectorization. It’s mostly a question of willingness to devote resources to the problem and hire folks (e.g. Aart Bik, who literally wrote the book on vectorization at Intel and is now working on the TF compiler team at Google and contributing to LLVM).

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

#78

Post by stephencanon »

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…

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, though I’m not sure what the current status is, since the initial reaction was not overwhelmingly positive.

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

#79

Post by gumby »

pjmlp wrote: post #67
yjftsjthsd-h wrote: post #62

Earlier quoted context omitted.

I'm not sure I understand. Are you predicting that open source is a passing fad, or that is will paint itself into a corner?

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, using it to simultaneously generate a scorched-earth moat around their respective castles while hiding proprietary extensions behind a network connection. I do not consider this to have been good for the software world at all.

As I'm sure you know your prediction has been made for 30 years. Doesn't mean it can't come true but unlike you I don't see the tide moving that way.

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

#80

Post by pjmlp »

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…

Android proves exactly my point of view, specially AOSP versus what is running on this phone.

The Linux kernel is the only surviving piece of GPL code on modern Android.

Just wait when Fuchsia becomes mature enough.

Post reply on HN