https://www.nextplatform.com/2023/05/02/the-skills-gap-for-fortran-looms-large-in-hpc/ The Next Platform * Home * Compute * Store * Connect * Control * Code * AI * HPC * Enterprise * Hyperscale * Cloud * Edge Latest * [ May 3, 2023 ] AMD Says AI Is The Number One Priority Right Now AI * [ May 2, 2023 ] The Skills Gap For Fortran Looms Large In HPC HPC * [ May 2, 2023 ] After The 2022 Bump, Arista Is Back To The Grind In 2023 AI * [ May 1, 2023 ] Just How Big Are Nvidia's Server And Networking Businesses? Compute * [ April 28, 2023 ] Of Course AWS Revenues Are Slowing And Profits Are Pinched Cloud * [ April 27, 2023 ] The Beginning Of The Bottom For Intel's Datacenter Business Compute * [ April 26, 2023 ] Broadcom Takes On InfiniBand With Jericho3-AI Switch Chips Connect * [ April 26, 2023 ] The Pure Unification Of Block And File Storage Store Search for: [ ] [Search] HomeHPCThe Skills Gap For Fortran Looms Large In HPC The Skills Gap For Fortran Looms Large In HPC May 2, 2023 Timothy Prickett Morgan HPC 14 [fortran-co] Back in the dawn of time, which is four decades ago in computer science and which was before technical computing went mainstream with the advent of Unix workstations and their beefy server cousins, the computer science students we knew at college had taught themselves BASIC on either TRS-80s or Commodore VICs and they went to college to learn something useful like COBOL and maybe got a smattering of C and Pascal, or occasionally even RPG, for variety. And more times than not, they learned these "real" programming languages on an IBM mainframe or minicomputer and sometimes on a DEC VAX. The nerds all learned to program Fortran, which was two years older than COBOL, which came on the scene in 1959, and which was used to digitize the complex formulas underpinning scientific workloads. Again, usually on either an IBM mainframe or a DEC VAX. By the time we learned a little Fortran at Penn State in the mid-1980s as part of an aerospace engineering degree on an IBM 3081, the jobs were all interactive but the hallways were still lined with walls of punched card boxes as legacy program storage. They represented a very weird past that bore more resemblance to a loom than a computer, as far as we were concerned. At that very moment, the university was installing Sun Microsystems workstations in its first technical computing lab, and in came Unix and C along with Fortran. And everything began to change. Penn State never became a supercomputing powerhouse like some American universities did, but the computing that was done there was typical of the time. Fast forward to today, if you look at the course catalog for aerospace engineering at Penn State, the only Fortran available to play with by students is one that is somehow tied to OneAPI, which makes no sense to us because OpenAPI is supposed to be data parallel C++. The programming courses in the aerospace engineering degree are dominated by C++, and C and MATLAB are also used. What happened to Fortran? A better question might be: What is going to happen to Fortran, and that is precisely the one that has been posed in a report put together by two researchers at Los Alamos National Laboratory, which has quite a few Fortran applications that are used as part of the US Department of Energy's stewardship of the nuclear weapons stockpile for the United States. (We covered the hardware issues relating to managing that stockpile a few weeks ago, and now we are coincidentally talking about separate but related software issues.) The researchers who have formalized and quantified the growing concerns that many in the HPC community have talked about privately concerning Fortran are Galen Shipman, a computer scientist, and Timothy Randles, the computational systems and software environment program manager for the Advanced Simulation and Computing (ASC) program of the DOE, which funds the big supercomputer projects at the major nuke labs, which also includes Sandia National Laboratories and Lawrence Livermore National Laboratory. The report they put together, called An Evaluation Of Risks Associated With Relying On Fortran For Mission Critical Codes For The Next 15 Years, can be downloaded here. It is an interesting report, particularly in that Shipman and Randles included comments from reviewers that offered contrarian views to the ones that they held, just to give a sense that this assessment for Fortran is not necessarily universal. But from our reading, it sure looks like everyone in the HPC community that has Fortran codes has some concerns at the very least. Employment Is Job One Just for fun, we broadened a set of search queries on Indeed.com that they did at the beginning of the report to provide some context for the skills shortage that the DOE labs that still have legacy Fortran applications are facing four decades after Fortran was a core part of an engineering education and was not unfamiliar to computer science graduates, either. If you go to Indeed.com and scan for Fortran jobs today, you will find 1,050 openings in the United States, Even COBOL has 1,228 jobs. This is in stark contrast to C++, which has 32,896 job openings, with C/C++ being mentioned in 15,192 openings. Java has 54,838 job openings, and Python has 83,591 openings. Only RPG, which is the analog to COBOL on the Power Systems platform running the IBM i operating system, has, at 659 openings, fewer jobs than Fortran. (And considering that there are still 120,000 companies worldwide using that IBM i platform, that says more about the constancy of the RPG programmers and their companies than it does about the strength of the market.) Perhaps this is the case with the Fortran programmers of the world, too. But we can assure you that the RPG shops of the world are having their own skills crisis as experienced programmers start retiring - or getting sick or dying in some cases - and will do so at a growing pace in the coming years. Fortran is having no easier time, and neither is COBOL. The good news for some HPC simulations and models, both inside of the National Nuclear Security Administration program at the DOE and in the HPC community at large, is that many large-scale physics codes have been rewritten or coded from scratch in C++, and moreover Python has become the dominant language for analysis applications - just like in the world at large. There is still a large pool of Java programmers who work on system and application programs written in that language, but any time you need performance, you usually don't choose Java. If some Java application or framework is important enough, then it is often ported to C++ for performance reasons. (Java is too far away from the iron, even if it is in theory easier to program.) The skills issue with Fortran is apparently not just about learning Fortran, but more about being associated with Fortran and all of the legacy baggage that has given its vintage and its low marketability going forward. "It should be noted that training staff in the use of Fortran is not a major challenge if the staff member has sufficient experience in another programming language," the Los Alamos researchers write. "Attracting (and retaining) staff in these large Fortran projects may prove more difficult. It is also possible that as the pool of Fortran developers continues to decrease, the demand for this skill set on legacy code bases across the industry will remain flat for quite some time, meaning increased competition for the relatively few developers with deep Fortran expertise. This has the potential to further erode retention and our ability to compete on salary." This is a different problem from the technical development of Fortran itself, which was explained well in the State of Fortran 2022 edition published by the IEEE last March, which you can see here. But even this report admits Fortran has its issues, and outlined them thus: "First, the lack of a standard library, a common resource in modern programming languages, makes mundane general-purpose programming tasks difficult. Second, building and distributing Fortran software has been relatively difficult, especially for newcomers to the language. Third, Fortran does not have a community maintained compiler like Python, Rust or Julia has, that can be used for prototyping new features and is used by the community as a basis for writing tools related to the language. Finally, Fortran has not had a prominent dedicated website - an essential element for new users to discover Fortran, learn about it, and get help from other Fortran programmers. In the same way, Fortran is no longer widely taught to university students or valued as a useful skill by industry. As a consequence, adoption of new users has been stagnating, large scientific Fortran projects have been migrating to other languages, and the communities of Fortran programmers remained scattered and isolated." And as a consequence, as the report from the Los Alamos researchers points out, in many cases the DOE's HPC centers may be the only customers pushing for Fortran support on future dataflow engines or other novel architectures that might come along. This is the real crusher. The sense we get from both reports is that the lack of a standard library is not so much of an issue when it comes to CPU-only parallel processing, where Fortran works well. The support for GPUs accelerators is weaker and fragmented, and the researchers called out the current "Frontier" exascale system at Oak Ridge National Laboratory and the impending "El Capitan" exascale system that is set to go into Lawrence Livermore National Laboratory, whose software ecosystem supports C and C++ applications a whole lot better than it does Fortran applications. "Multiple competing standards for Fortran-based GPU programming with varied levels of robustness and support exist today (Fortran OpenMP Target offload and OpenACC)," the researchers write. "Neither of these technologies is robustly supported on the AMD GPU (MI250) today." To be fair, that is why Oak Ridge and Lawrence Livermore got access to cheap flops - so they can help fix the software issues. Hence, the Exascale Computing Project in the United States is working on Flang, an open source Fortran compiler based on the LLVM compiler toolchain, which is a kind of middleware that sits between a compiler front end and a compute engine instruction waiting attentively for work at the backend. Sorcery, now a part of Siemens Software - yes, a division of that German industrial giant - is working on OpenMP targets offload and OpenACC backends for the gfortran compiler in the open source GCC compiler stack that is often affiliated with Linux. "Both efforts are largely reactionary, due to poor community and technology provider support for Fortran on advanced technologies," Shipman and Randles say in the report. Things often are would be our observation. The question is will the reaction be strong enough to overcome inertia. . . . Here are the seven risks that Fortran faces in HPC as Shipman and Randles see it: * It is very likely that we will be unable to staff Fortran projects with top-rate computer scientists and computer engineers. * There is an even chance that we will be unable to staff Fortran projects with top-rate computational scientists and physicists. * There is an even chance continued maintenance of Fortran codes will lead to expensive human or financial maintenance costs. * It is very unlikely that codes that rely on Fortran will have poor performance on future CPU technologies. * It is likely that codes that rely on Fortran will have poor performance for GPU technologies. * It is very likely that Fortran will preclude effective use of important advances in computing technology. * There is an even chance that Fortran will inhibit introduction of new features or physics that can be introduced with other languages. "Our assessments lead us to the view that continued use of Fortran in our mission critical codes poses unique challenges for LANL," they say, and indeed for any other HPC center that relies on Fortran. "While Fortran will continue to be supported at some level, particularly on CPU-based systems, the outlook for advanced technology systems is dim. The ability to leverage broader and more modern open source technologies/frameworks is unlikely, increasing the cost of new physics and feature development." While not bleak, that assessment is also not encouraging. But, maybe it will encourage the powers that be, who control the purse strings, to invest more in Fortran tools and Fortran programmers. This will be a heck of a lot cheaper than porting all of those applications. But, in the longest of runs, maybe that will be necessary anyway as Fortran programmers age out and the pool of programmers who can - and will - take on NNSA codes and not only master them, but enhance them, shrinks. Our observation would be this. Back in the early 1990s, it was not precisely cool to be a nuclear weapons designer. But the Comprehensive Test Ban Treaty of 1996 and the massive investment in simulation and modeling, coupled with the test data from over 1,000 nuclear bomb explosions, gave a different set of people new tools to tackle a bigger problem, and it attracted some of the smartest minds on the planet to design systems and software to take on the simulation task. Fortran needs something to make it cool again, something more than nuclear weapons, which for a lot of the youth these days is not a plus, but a minus. It certainly was for us, which is how we ended up writing The Next Platform, among other things, and coming to a kind of detente of our own that these weapons do exist and they do perhaps provide some kind of deterrent to World War III. If you want to sell it to this generation, that is how it might be done. As crazy as that might sound. Sign up to our Newsletter Featuring highlights, analysis, and stories from the week directly from us to your inbox with nothing in between. Subscribe now Related Articles [ab_wood-crates-stacked-326x245] HPC Mythbusting Containers, The Los Alamos Way December 11, 2019 Dan Olds HPC 0 As is the case with any new technology, there is a lot of hype and misunderstanding that comes along with something that actually improves some aspect of the system. Containers are no exception, and one has to separate the reality from the exaggeration and confusion to figure out how to ... [two-roads-diverge-326x245] Compute The Art Of System Design As HPC And AI Applications Diverge October 6, 2022 Timothy Prickett Morgan Compute 5 Predicting the future is hard, even with supercomputers. And maybe specifically when you are talking about predicting the future of supercomputers. As we noted many years ago, the fact that AI training workloads using convolution neural networks came along with enough data to actually start working at the same time ... [nvidia-gtc-2021-grace-cpu-hopper-gpu-326x245] Compute Nvidia Enters The Arms Race With Homegrown "Grace" CPUs April 12, 2021 Timothy Prickett Morgan Compute 8 There has been talk and cajoling and rumor for years that GPU juggernaut Nvidia would jump into the Arm server CPU chip arena once again and actually deliver a product that has unique differentiation and a compelling value proposition, particularly for hybrid CPU-GPU compute complexes. And today, at the GTC ... 14 Comments 1. [562e58] Lev says: May 2, 2023 at 8:47 pm I was under the impression that fortran-lang.org was a page entirely dedicated to FORTRAN and dissemination of information and standards. As for standard tooling, this does not seem to hurt the C/C++ case. Not familiar with HPC world, but on Linux, Sun and IBM I can build FORTRAN with GNU and vendor tools and use CMake to manage projects. Reply 2. [11e8aa] Eric Olson says: May 3, 2023 at 12:08 am The idea of a valuable legacy worth passing down from one generation to the other requires forming the next generation in a way that can appreciate the efforts and fruits of the previous. This is easy with a legacy of gold coins-less so with Fortran. Are the people who sold the family farm because it was more fashionable to live in the city the same who tossed out Fortran for lack of curly braces? Just like the Cray-style vector processors went out of style after years of dominance, it may happen that GPU offload technologies will go out of style in favor of something else. For example, maybe the evolution of the Fujitsu a64fx and the Intel Xeon Max will lead to CPUs that run Fortran faster than the GPUs can run CUDA or HIP. Could the Vector+1 extensions to the Power ISA being proposed by Red Semiconductor coupled with on-package high-bandwidth memory turn out to be an even better fit for Fortran? It's not clear to me whether adding language features built around GPU technologies would be consistent with the longevity goals that Fortran codes have enjoyed so far. I also wonder if CUDA programs will even be useful after another 10 years. Reply 3. [17f519] Dmitrii Demenev says: May 3, 2023 at 3:13 am I genuinely liked Fortran when I learned its basics. However, the lack of job openings concerned me even though I'm a Rust developer. I couldn't find big active open-source projects in Fortran so I couldn't see how it's actually used. Reply 4. [2ea34c] Carl Schumacher says: May 3, 2023 at 10:06 am Fortran was the first language taught in my first computer science classes (both in High School in 1974, then in college Fall 1975). I never ended up using Fortran professionally though...My initial decade as a programmer was more various assemblers then on to C. Perhaps if I had gotten a job at the NASA facility that I drove by commuting to college every day, Fortran would have had a bigger impact on my programming career. The last 10 years of my IT career, ending in 2021 at age 64 as a Linux systems admin of 5,000 servers, was mostly shell scripting along with a bit of Python. Reply 5. [0c3360] Bob says: May 3, 2023 at 10:12 am Fortran was (and is) not used just for nuclear weapons! There is plenty of Fortran code still around for quantum physics, protein modeling, climate modeling, astrophysics, fluid dynamics, etc. Admittedly most of it is legacy code, even though still widely used, and newer projects tend to use other languages, but the notion that Fortran needs something "other than nuclear weapons" to make it cool doesn't make sense to me. It has and always had other things to do. Now, whether Fortran can ever be made cool is a separate question. Reply + [f253c1] Timothy Prickett Morgan says: May 3, 2023 at 10:20 am Well, of course. But the nuke guys are the ones who are worried. Reply o [b78ea0] DOE alum says: May 3, 2023 at 11:34 am There are lots of nuke people. Galen and Tim are not in charge of nuclear weapons, or anything close to that. They are computer people in support of the mission software activities. You're making a mountain out of a mole hill. You should interview somebody who is actually responsible for the nuclear mission software activities. Reply # [f253c1] Timothy Prickett Morgan says: May 3, 2023 at 3:34 pm I don't think I ever implied that they were anything other than software people supporting the mission. As for mountains and molehills, I reported on what they said and added some references to another report as well as some ideas of my own about actually learning Fortran a long time ago and thinking it was pretty cool and was surprised it was not really required the same way as when I was in school. Reply 6. [50fb69] Thomas Hoberg says: May 3, 2023 at 12:23 pm Funny, with that name of yours I always had you down as a Brit... We weren't far apart then: in 1980/81 I took a quarter of evening classes at a community college in BASIC programming on a TRS-80 as a senior in High-School (South-Western Ohio), then did another in Fortran and Cobol on an IBM mainframe with these wonderful 3270 terminals. Paper punchers were still in the same room and I did take home both card stacks and tape copies of my collected works before returning to Berlin: I was there as an exchange student. I revisited Fortran two times after, one was an industrial project re-factoring an industrial control system from PDP/11-05 machines (probably assembler originally) to an LSI-11 based variant using Fortran-77. Then I worked for many years with a team of meterologists who had vast libraries of code simulating the effects of smog and pollution under the influence of humidity and sunshine using Navier-Stokes equations for the chemistry and much simpler statistical models for the air-flow in box models. There my main job was to find an CDC 6000 replacement which turned out to be a series of 80386/80486 computers with the faster Weitek 1167/4167 co-processors and a matching compiler on ISC System V Release 3. I'd been running Microport Sys V.2 on my 80286 even before that (including a DOS box!), and it's been mostly x86 since, with a heavy emphasis always on infrastructure, high-availability but also HPC. There was some early work with Suns and mainframes and I've always tried to bring their best qualities (the network is the computer and virtualization) to x86 infras. I did a lot of coding early, and during my computer science studies, especially for the thesis, but for some reason my professional career was far more in operations, where I kept reading code and fixing bugs made by others, but wrote ever less code. Much later in my career I was still dealing rather indirectly with a huge body of software written in Cobol, but there it's main effect was that I could talk with those people who maintained it on a mainframe: I'd been there, done that too, I knew the lingo and I could look at the code, which very often produced the interface files that caused us grief on the C++ or SQL end of things. Today my coding skills are probably as good as my Latin, which has completely rusted out while I became near native in four modern human languages, having to become fluent in French in my fifties and in Spanish in my thirties. The worst issue is that for a long time I could never decide which one (programming language) to use as a primary... there were so many and I liked most of them better than my first three (BASIC, Fortran & Cobol). I loved Prolog, ML and Occam, but they were impractical as daily drivers. I also liked Lisp, Scheme and Smalltalk, but again they were far from mainline. I did lots of Turbo-Pascal at one point, then it was mostly ANSI-C, but when it came to OO, far too much really badly written C++ code turned me off and then there were 4GLs or simply others to write the code. I still enjoy reading good code almost as much as I enjoy reading good baroque sheet music, ...doesn't mean I can do it myself. Reply + [f253c1] Timothy Prickett Morgan says: May 3, 2023 at 1:21 pm My many lines of forebears was thrown out of several European countries in the 1600s and 1700s and came here on various boats. I'm as American as they get. But still mostly Anglo-Saxon with some Irish, German, Dutch, and Italian thrown in for good measure. Reply 7. [cee6f3] Keith Bierman says: May 3, 2023 at 1:10 pm "The nerds all learned to program Fortran, which was two years younger than COBOL, which came on the scene in 1959," you seem to have inverted history. The original Fortran predated the original COBOL. yes, COBOL was available in 1959 (leveraged Hopper's Flowmatic) but the original IBM Fortran was from 1957 making it *older* not younger than COBOL (and also Algol). Reply + [f253c1] Timothy Prickett Morgan says: May 3, 2023 at 1:17 pm I did! Sorry about that. Reply 8. [e36477] DRB says: May 3, 2023 at 2:06 pm 20 years ago I was at NCSA, and disturbed to learn that over half (and growing) of the code was C++, even though FORTRAN ran at that time about 30% faster. (Caveat: I was in a compiler group and the gap may have closed since then...) From my perspective, that was like funding a full machine costing many hundreds of millions of dollars, and throwing away a third in pursuit of ease-of-programming. But that was, and likely still is, the reality of software development. The only option given that is to simply fund a rewrite of the nuclear sim codes. Reply 9. [1aa540] Eric Garner says: May 3, 2023 at 3:08 pm The reason that you see it mentioned in the OneAPI course is because Intel rolled the Intel Fortran Compiler into the OneAPI toolkits. Reply Leave a Reply Cancel reply Your email address will not be published. Comment [ ] [ ] [ ] [ ] [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. About The Next Platform is published by Stackhouse Publishing Inc in partnership with the UK's top technology publication, The Register. It offers in-depth coverage of high-end computing at large enterprises, supercomputing centers, hyperscale data centers, and public clouds. Read more... Newsletter Featuring highlights, analysis, and stories from the week directly from us to your inbox with nothing in between. Subscribe now * RSS * Twitter * Facebook * LinkedIn * Email the editor * About * Contributors * Contact * Sales * Newsletter * Books * Events * Privacy * Ts&Cs * Cookies * Do not sell my personal information All Content Copyright The Next Platform