12 ms·
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 mu
by tikej 7y ago
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, but also other languages to be clear. Of course I’m very grateful for LLVM project, it’s absolutely great. I think that the idea to focus talent pool from many languages is brilliant and beneficial for everyone. The only problem is when it becomes so focused that it becomes only option. I am very happy for variety and options for compilers and backends we have now.
- chrisseaton 7y agoThe 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.
- tikej 7y agoOh maybe I missed it. Is there a way to compile LLVM IR with something other than LLVM? Is this what you mean by output of LLVM front-end output?
- aneutron 7y agoI do believe this is what OP meant. The LLVM IR is very well documented, and can in theory be plugged into a back-end that supports it.
- tikej 7y agoAh, 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.
- johannes1234321 7y agoThere 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 lots of improvements in gcc/g++. Produced code got faster, diagnostics better etc. Sure, Fortran is a different area, with less commercial interest a d other challenges. (LLVM is pushed by Apple and Google for non-Fortran needs - it is thinkable that they push decisions, which hinder Fortran, whereas gcc has a different goal and might long term more receptive to Fortran needs?)
- celrod 7y agoI 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/32843 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 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.
- gnufx 7y agoIs 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.
- chrisseaton 7y agoI think so - I’ve worked on an LLVM backend completely independent of LLVM.
- debugbreak42 7y agoNot 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.
- gnufx 7y agoI'm well aware of Fortran runtimes. The question was getting at whether the front end is completely independent of the middle(?) end.
- wrmsr 7y agoIt's stated that llvm ir is not stable (https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-comp...) and in my relatively limited experience with it there have been enough differences between every little release to make decoupling even official frontend and backend versions not safe or reliable (much less bolting on and maintaining an unofficial backend impl). If bundling/pinning the flang/clang versions with the supported llvm ir version supported by the alternate backend is feasible (which seems sane) then I definitely agree this is an awesome capability (clang-on-sulong) but given how unapologetically volatile llvm ir is I wouldn't exactly call it 'free' :p (but still a lot better than writing a c++ frontend)
- kryptiskt 7y agoI'm hoping for Cranelift (https://github.com/bytecodealliance/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 https://www.graalvm.org).
- throwaway894345 7y agoI 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.
- chrisseaton 7y agoI 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.
- throwaway894345 7y agoSo 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?
- chrisseaton 7y agoIt'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.
- Ididntdothis 7y agoI am not a compiler expert but I wonder if FORTRAN will lose its speed advantages it still supposedly has if it goes through LLVM.
- Fronzie 7y agoAs 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.
- cygx 7y agoC/C++ does not have alias-annotations built-in Restrict?
- stephencanon 7y agoFortran 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.
- gnufx 7y agoActually, 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.
- stephencanon 7y agoNumeric 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.
- ausbah 7y agoWhat exactly is the benefit of having multiple compilers? I'm not well versed in the area, but it seems like having one compiler is better from the perspectives of standardization, having a single way of handling undefined behaviors, etc?
- smichel17 7y agoWith a permissive license, it's vulnerable to embrace, extend, extinguish.
- est31 7y agoThe 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 fork clang and put it under GPLv3 or similar.
- mitchty 7y agoIf 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.
- cultus 7y agoI 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.
- Bostonian 7y agoIs ifort "big business" in terms of direct revenues from sales of the compiler or because it makes Intel hardware a faster platform for HPC?
- cultus 7y agoBoth. 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.
- Someone 7y agoLet’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.
- celrod 7y agoI'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.
- gumby 7y agoDon’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.
- pjmlp 7y agoAs 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.
- yjftsjthsd-h 7y agoI'm not sure I understand. Are you predicting that open source is a passing fad, or that is will paint itself into a corner?
- pjmlp 7y agoI 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.
- gumby 7y agoI 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.
- gnufx 7y agoI 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.
- bondant 7y agoFrom what I've seen, PGI's offloading (with OpenACC) still delivers better performance than GCC, although GCC is improving. Also PGI usually give better error messages or comments about what it's doing when offloading. But yes offloading with PGI is for Nvidia cards only, and GCC contributors are working on adding support for offloading to AMD GPUs.
- noobermin 7y ago>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.
- TheRealKing 7y agoI second that.