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

91–97 of 97 posts

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

#91

Post by gumby »

riffraff wrote: post #88
gumby wrote: post #79

Earlier quoted context omitted.

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.

The affero license is useful for things accessed over the web, which of course became quite important and thankfully the GPL catching up.

I wrote the library license back in the early 90s because of a similar shift (Unix and Windows were late adopters of the the philosophy of libraries, not just programs, for non- system code, but once they finally started to get on board the GPL had to catch up)

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

#92

Post by gnufx »

celrod wrote: post #83
stephencanon wrote: post #78

Earlier quoted context omitted.

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?

I don't know how omp simd is related to "blocking", but it can slow code by a factor of two compared with GCC optimizing the loop normally, because you get AVX(51)2 but not FMA. (Observed with a generic C GEMM, which got about 60% of the micro-optimized one after removing such pragmas and just letting gcc do its -Ofast thing.)

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

#93

Post by TheRealKing »

noobermin wrote: post #72
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…

I second that.

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

#94

Post by pjmlp »

jcranmer wrote: post #61
johannes1234321 wrote: post #26

Earlier quoted context omitted.

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…

> Sure, Fortran is a different area, with less commercial interest a d other challenges. Actually, it's quite the opposite. You're never going to make money selling a C/C++ compiler, but you can make loads of cash selling a Fortran compiler. It's just that the Fortran compiler is likely to come with your supercomputer.

C and C++ Compiler vendors targeting embedded, security critical domains, or Intel, PGI, Embarcadero, Microsoft, Oracle, Intel, HP, IBM, Unisys, CodePlay might disagree.

There is plenty of money to be done in C and C++ commercial compilers, it just depends on the customer base, and features missing from clang/gcc regarding overall tooling experience.

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

#95

Post by pjmlp »

Gibbon1 wrote: post #81
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.

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.

It has been done multiple times in safe C dialects, the problem is the community, not technical.

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

#96

Post by stephencanon »

gnufx wrote: post #84
stephencanon wrote: post #65

Earlier quoted context omitted.

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 gen…

Yeah, I'm using the C nomenclature ("aliasing" vs "association") because HN commenters are broadly unfamiliar with Fortran.

What I mean by "default" is that if I declare a function with two array arguments in Fortran, with the simplest possible syntax, the compiler assumes that they do not alias (are not associated). By contrast, if I declare a function with two pointer arguments in C, with the simplest possible syntax, the compiler assumes that they may alias (are associated in some unspecified manner).

The C semantics are certainly safer, but they lead to lots of "Fortran is faster than C" blog posts by people who either don't know about or simply don't want to use the annotations.

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

#97

Post by TheRealKing »

Ididntdothis wrote: post #27
palae wrote: post #16

Earlier quoted context omitted.

A bit of a nitpick maybe, but it's been Fortran and not FORTRAN for quite a while (since Fortran 90 in the 90's).

“since Fortran 90 in the 90's” That’s when I used it last time :)

still being used in our research group on a daily basis.
Post reply on HN