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

51–60 of 97 posts

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

#51

Post by debugbreak42 »

gnufx wrote: post #41
chrisseaton wrote: post #4

Earlier quoted context omitted.

The great thing is anyone could take the output of the Fortran LLVM front-end, and then compile that however they wanted with their own compiler technology. LLVM doesn't need to mean consolidation of backends. It can just mean you get a front-end for free, if that's all you want.

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.

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

#52

Post by zengid »

I'm excited to see more front ends embracing MLIR.

A lot of new interesting languages (Julia, Rust, etc) were empowered by being able to take advantage of LLVM as a backend, so I can't imagine what new languages might spring up around the heterogenous capabilities of MLIR, not to mention existing languages targeting it as well.

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

#53

Post by gilnaa »

dsqrt wrote: post #25
Fronzie wrote: 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 has the "restrict" keyword to indicate that no aliasing should occur.

But is mostly unused and mostly irrelevant

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

#54

Post by cultus »

Bostonian wrote: post #45
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.

Is ifort "big business" in terms of direct revenues from sales of the compiler or because it makes Intel hardware a faster platform for HPC?

Both. They are able to optimize things on Intel processors that no one else since they are the ones that make the processors and have more proprietary information and such. It's closed-source freeware but they make money on support.

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

#55

Post by celrod »

cultus wrote: post #14
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,…

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 will change things, but until I test I have no idea by how much.

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

#56

Post by pjmlp »

gumby wrote: post #38
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,…

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.

As mostly user of commercial software, it hardly affects me, but it is going to be interesting to watch when all copyleft software gets into a niche and we get back what was basically shareware and PD on the home computing scene.

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

#57

Post by Someone »

Bostonian wrote: post #45
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.

Is ifort "big business" in terms of direct revenues from sales of the compiler or because it makes Intel hardware a faster platform for HPC?

Let’s say your hardware cost $1 million. Then, a compiler that brings you a 1% speed increase compared to a free one should be break-even at a license price of $10,000, possibly more if you factor in the cost to run that machine. $1 million computers are rare, but not that rare (The fastest in the top-500 cost over $100 million), so, _if_ you can build a compiler that consistently does that, there should be a profitable business there.

I would think margins on CPU sales and on consulting would dwarf that 1% margin, though. Because of that, I think it’s more “winning the benchmarks game, because that’s what sells hardware there” then revenues from compiler sales that keeps intel’s compiler alive.

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

#58

Post by jcranmer »

mitchty wrote: post #30
est31 wrote: post #21

Earlier quoted context omitted.

The ability to make it proprietary is in fact the reason why Apple didn't adopt gcc and became the main supporter of clang/llvm instead. So the issue is already here. Fortunately Apple's ambitions only center around keeping full control of the Apple walled garden (the apple main building is a wonderful symbol of it). And should a strong proprietary competitor outside of Apple's ecosystem emerge, people can always for…

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.

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

#59

Post by lloda »

fctorial wrote: post #19

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

I write mostly C++ and Scheme and last year I wrote my first piece of code in modern Fortran (I had some experience porting/integrating old F77 libs). It's trivial to interface with C and lets you do numeric stuff immediately and without libraries using a plain syntax. Compared to C++ with template array libraries it compiles much faster and doesn't get in your way nearly as much. It has a module system... Compared to numpy/matlab/etc it takes some adjusting b/c it's still a lowish level language (errors lead to segfaults, etc.) but a lot less than going to C/C++.

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

#60

Post by celrod »

johannes1234321 wrote: post #26
tikej wrote: post #10

Earlier quoted context omitted.

Ah, ok yes. But in my OP I didn’t really mean technical problems, rather organisational/social. I mean that if all top-class talents in compilers technology focuses on llvm there probably wouldn’t be a lot people to be both willing and able to write alternative backends.

There will always be somebody interested in doing something else. Somebody considers that something can't be represented nicely in LLVM IR and creates their own thing. Somebody can't work with LLVM folks for social reasons and creates their own thing. Reasons there are many and thus at some other point something successful will challenge them. For the C++ world the competition by LLVM/clang was fruitful and triggered…

I think that is possible.

I've been thinking a lot about vectorizing loops recently, especially on AVX512 systems. I've mostly been doing microbenchmarks, and I realize that microbenchmarks might not give a realistic full-program view.

LLVM (through Julia and Clang) have a striking performance pattern as sizes vary: https://discourse.julialang.org/t/ann-loopvectorization/3284...

They are fast at multiples of 32, but then performance degrades. This is because it vectorizes loops by creating two loops:

  1. 4x unrolled and vectorized (with double precision and AVX512, that translates to 4 * 8 = 32 loop iterations)
  2. Scalar loop.
By avoiding that pattern, it was easy to get much better performance at most sizes in a lot of simple cases, like dot products.

In wondering about why LLVM's decisions made sense for them, I'm currently leaning towards AVX transition penalties being a big factor. Recently shared on HN: https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html

The thing that struck me is that there is a 9 microsecond period where avx instructions (AVX2 and AVX512) operate at a small fraction of normal speed before the CPU decides to transition to a slower state.

If most of your code is running in L0 (max clock speed) license, then any vectorized code you run into will run at 1/4 speed for about 9 microseconds. If it does run for that amount of time, it'll transition with an 11 microseconds break. It'll have to keep running for a long time to amortize this penalty.

Then, once the function returns to the rest of your scalar code, it'll eventually have to speed up. Basically, large programs are probably fastest if they stay in relatively the same state.

By having a large scalar window, like LLVM does, it's less likely to change. Most loops are probably fairly short, and most code is also scalar, therefore you'll want the CPU to generally stick to scalar mode. Only if loops are very long and likely to take milliseconds would you want them to be vectorized.

Or if they're surrounding by other SIMD code, but that's a sort of global/whole program state you cannot infer while optimizing a single function.

It is likely best to go lean very heavily to one side in your preference of scalar vs vector, but which side is better varies by program. LLVM is essentially leaning heavily toward scalar in their loop behavior, which is probably best for most C and C++ programs. Many Fortran programs might prefer vector. My own (Julia) code does. But I have a hard time talking about Julia or Fortran programs in the abstract. I tend to ensure vectorization. Most programmers don't, so even in these languages, they're likely to prefer and benefit from different defaults than I do.

Post reply on HN