In a new 19-minute video, two LLVM Flang developers cover
the current status of Flang, the features it supports and how its performance compares against that of other Fortran compilers. In particular, improvements and bug fixes driven by Fujitsu and GFortran test suites, which contain years of code derived from real world usage and that now, for the most part, work with Flang. Other highlights are full support for polymorphism and OpenMP 1.1 and partial support for procedure pointers, C-interoperability, OpenACC and later versions of OpenMP.
Just curious if there is any date mentioned when I’ll be able to do something like
sudo apt install llvm-flang
and have a working compiler on my Linux Mint systems.
I guess the developers are doing the best they can but this project has been going on for what 5 years now. I would think they would be farther along than what you outline. We went to the moon in about 8 years and it’s looking like llvm-flang is going to take longer than that.
Well, LLVM Flang is an open source project funded by the companies supporting it and other volunteers.
According to a CBS News article, it’s estimated that the modern cost of just the Apollo command and service modules, the lunar modules and the Saturn rockets would be about $100 billion dollars. (In terms of percentage of GDP, that would be about $700 billion.)
My many years experience in the aerospace industry has taught me that projects that underperform and get behind schedule (although there appears to be no defined schedule for llvm-flang) are usually the result of ineffective leadership not a lack of funding or incompetent staff. Going to the moon was rocket science. Writing a compiler is not.
An estimate I’ve heard: A new compiler from scratch takes about 5 years to get something usable, and about 10 years to get an optimizing compiler that you can rely on and depend on in production. Based on my experience this seems spot on.
Note that if we count from the original Nvidia announcement it’s more like 9 years. But I guess the “old” flang isn’t what is being worked on now? (I know there is some story there…but not sure what it is). I’d be interested to know the inside story there.
It’s quite common for large software projects to take longer than anticipated. It’s the central theme of Fred Brook’s book “The Mythical Man-Month” that gave rise to Brooks’s law. I don’t want to dwell on whether that’s also the case for flang.
I remember reading stories of how software delays were also the culprit for F-35 fighter jet being years behind schedule. Not to mention the software responsible for horizontal stabilization of the 737 Max. So I think aerospace has its own software issues.
I have fond memories of the Fortran ground based simulation software used in the European fighter project. The UK MOD outsourced to a private company and they got rid of the bloke who had written most of the software. His junior then said he was leaving too. Outcome was I ended up providing crash training in Fortran to two new employees, both in their 20’s. The bloke who had written the software was paid to come back on a consultancy basis at £2,000 per day. His junior got a £15,000 a year pay rise to keep him on until the two new people were up to steam.
Quietly started in 2015, I believe. It was two years in when I joined NVIDIA in 2017 to work on Flang (what is now Classic Flang). I believe we didn’t publish that on GitHub until 2017.
Thanks @gak. Ok, so it’s a much newer endeavor than I thought. Yes, your push to github was a motivation for both LFortran and new Flang. I believe November 2017 for both.
I would say the clock starts ticking once you put the full effort into it. So the Classic Flang is 9 years old (perhaps a bit less if you don’t count the first year), and it’s quite mature, but didn’t quite deliver on the original hope to support all of Fortran. The new Flang is from 2017, but maybe you want to start counting a little bit later, so it’s around 6 years old.
And LFortran is from 2019 when I started working on it seriously, but I took a year off to help bootstrap fortran-lang, so maybe a little over 4 years old or so.
Now, the NAG compiler I believe was done in only about 1.5 years in 1990, maybe @themos can clarify, but back then it was only F77 and F90, which I think both Flang and LFortran support pretty well by now. It’s just that Fortran 2023 contains a lot more features.
If anyone knows time frames for other Fortran compilers, I would be interested. g95/gfortran, Intel, Cray, etc. I believe Intel said it took them 5 years to port ifort to LLVM (ifx)?
It all points to about 5 years to have something reasonable, and 10 years to full production.
Perhaps the blame may be attributed to history repeating itself.
An internal CDC report is available on Bitsavers, on page 8 of which we can read:
Current Competitive Position
A. Sales problems and current customer attitudes
The 6600 is not doing as well in the market place as could be hoped for. On running benchmark problems, it is embarassingly poor on compute speeds as well as on thruput. The most embarassing aspect is that the 6600 is only producing marginally better compute time than a machine costing one half as much and having less than one third the compute capability, the UNIVAC 1108. The 6600 is not even greatly outstanding relative to the IBM 7094-X series and these machines have less than ten percent of a 6600’s compute power. It is these two comparisons that are hurting us most in the market place, notably in the following instances:
The Air Force represents a market potential of from five to twenty-five 6000 series machines. They require essentially three times the power of a 7094-II. The 6600 is falling down in both compute speeds on FORTRAN jobs and thruput of the system.
AVCO requires a machine four times the power of a 7094-I and we fail there.
The Weather Bureau has an office which essentially wants to run one large compute bound FORTRAN program and on a price-performance basis we lose again, here to an 1108. Certainly a more comprehensive survey of Marketing would produce more examples of a similar nature. The part that seems most awkward is that the 6600 is a machine with a huge computing capacity; the operating system and peripherals are structured for this environment, but the FORTRAN compiler is only designed for efficient handling of small, short-run-time jobs.
The report is dated 6/1966 (how apt for the topic of a Fortran 66 compiler for the CDC 6600!) Towards the end of the report (p.39) we can see the cost estimate for the proposed optimizing compiler: $ 320,000.
Three years earlier, Thomas Watson Jr. of IBM had lamented, “Contrasting this modest effort with our vast development activities, I fail to understand why we have lost our industry leadership position by letting someone else offer the world’s most powerful computer.”, to which Seymour Cray gave his famous riposte: "It seems like Mr. Watson has answered his own question.
Based on my personal experience with seeing the features most Fortran programs use, I think LLVM Flang turned a very significant corner when support for polymorphism was added a few months ago. For anyone willing to build LLVM Flang from source, I recommend trying LLVM Flang now. I have a shell script that I use for building LLVM Flang from source and that I’d be happy to share with anyone who wants it. The script is just my way of recording my steps so that I don’t have to remember them every time. It only does a very tiny amount of system introspection and will almost certainly need modification on other people’s systems, but at least it means you might not have to start from scratch and read the documentation on building LLVM Flang.
I’m sufficiently excited about the state of Flang, that I’m about to do some minor refactoring of three repositories to ensure that Flang can build all three. I hope to be able to move toward Flang being my default compiler for a lot of my work before too long.
To be clear though, my statements above relate only to feature support. I have no first-hand knowledge of how LLVM Flang compares to other compilers in terms of performance, but from Ondrej’s statement above, I suspect it will take some time to go from supporting the features most programmers want to generating fast code.
That 1966 time frame would have been using the RUN Fortran compiler (written by Garner McCrossen and team) on the original Chippewa Operating System (written in raw machine code by Mr Cray) on hardware that was barely working. Eventually the FTN compiler series developed in the 1970s and '80s could generate very good optimized code for the 6000 series, 7600, and Cyber 70/170/180 systems.
The CDC compilers and operating systems of the day were written the old fashioned way - in COMPASS (CDC’s assembly language). Though in later years they used SYMPL (CDC’s own version of a stripped down JOVIAL) for a lot of systems programming. Then, about the time I left the CDC world, CYBIL - which was based on PASCAL.
I believe November 2017 for both.