AFAIU there are some people in LANL that have been for quite a while on some kind of holy crusade against Fortran. Their opinions AFAICS aren't really shared by the computational science community at large, or the other US nuke labs for that matter. They regularly produce statements or reports like this one.
As for the question in the title, yes Fortran will be around in 15 years. Perhaps the share of Fortran in new developments is shrinking, but more due to Python, Julia, MATLAB and such, and not C++.
The report[0] is short and we'll written. What I like are the disagreements from the reviewers. I write a lot of Fortran[1] and I tend to agree with most of the points. Even the disagreements are all good because they take different but also raisonnable views at the problem.
Well, it's just a programming language, and not a particularly complicated one. It's closer to current languages than e.g. COBOL. People can easily learn it (if they are willing). And it can easily be transpiled to a GPU supported language, so the argument that there are no GPU compatible Fortran compilers is weak.
In that light the following statement of the article is really strange:
"While Fortran will probably run acceptably on future CPU technologies, it will likely perform poorly with GPUs because of the lack of robust Fortran compilers, the report said, noting that the ecosystem of tools is “significantly lacking in Fortran."
Intel and Portland compilers are excellent, nVidia having some home ground advantage in optimising. If I needed to run CUDA from Fortran it would be very straightforward.
Fortran is better at arrays than C++ and most other languages, which makes it better on GPUs too.
Compaq (an x86 shop which did little in the OS space) bought DEC. It kept making the non-x86 DEC hardware and software.
Then HP bought Compaq. HP had its own processor & OS families, and had persuaded Intel to work with it on the successor to HP's PA-RISC architecture: Itanium.
Part of that deal is that HP passed over some DEC IP it had acquired to Intel. Effectively this killed off a significant rival to Intel, and in theory, opened a path to market for Itanium.
So Intel got DEC's Alpha, the first 64-bit RISC and the fastest RISC on the market. It killed it. It also sold off its Arm division to Marvell.
The vast majority of implementations I saw and still see in the scientific community are plain Fortran 77. In the nineties and early 2000 most of it run on Irix, some on Solaris; today most is on Linux.
There was the Kuck(?) preprocessor for fortran and a whole lot of smart compiler work done for the mini-super market (Convex et al). How to get vector/parallel performance without rewriting dusty-deck codes. Algebra tuned quite well and easily. I think Rice was the school producing compiler experts going into these companies.
> The Lindy effect (also known as Lindy's Law[1]) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.
Does Fortran need to? Does Fortran still have any real advantage over Julia, MATLAB, etc.?
Please forgive my ignorance. I've never written any Fortran. I understand how and where it's used in modern computing though. I also understand why it's faster than C in some cases.
Does Fortran still have any real advantage over Julia, MATLAB, etc.?
Performance. Fortran is much still faster than Julia, MATLAB etc.
It's also much easier to write fast Fortran compared to fast C. While C code written by an HPC expert will almost always be as fast as Fortran written by an expert, C written by "mediocre" C programmer who is a domain expert solving a problem in the most obvious way, will basically always be slower than Fortran code written be an equally "mediocre" Fortran programmer.
Fortran isn't faster than Julia. most comparisons I've seen are ties or Julia wins as long as both implementations are somewhat competent.
Fortran actually makes it fairly hard to write fast code since it is missing some features. for example, I don't believe there is any way to write a fortran program using Bfloat16 numbers. you also don't have great ability to write programs with a mix of strict ieee semantics and fastmath semantics. you have to choose 1 as a compile time flag.
If you are ignoring the cost of the compiler, and a whole host of other things - sure. But the same can be said for most any modern programming language. A lot of Julia's public benchmarks are not idiomatic Julia or packages were created to elide how nonidiomatic they are. Julia isn't a slouch after precompilation, but the time to burn in code can be longer than the runtime and the compilation time of the code in other languages by orders of magnitude. It's great for academic benchmarks though! Huge pain for CI and development.
Are you not talking about Julia v1.9? Packages precompile to binaries (.so/.dll) in this release, and will support direct calls pretty soon. It sounds like you're talking about a much older Juila.
> A lot of Julia's public benchmarks are not idiomatic Julia or packages were created to elide how nonidiomatic they are.
I do enjoy programming in Fortran but let's at least keep it concrete and to reality. The older Fortran versions do have a small amount of optimizations that are hard to perform in other languages because the lack of aliasing can make difficult to prove optimizations possible. But the newer Fortran versions don't optimize as well without forcing things like ivdep, which is similar to Julia, which is why you tend to get the same/similar machine code between LFortran and Julia (since both are using the same compiler, LLVM).
If by much older you mean the current stable Julia release than sure... As of today Julia 1.8.5 is the stable release. So this post is traditional Julia community stuff.. "it works and everything is perfect you're the problem. We didn't create our own message board and stop posting in other places to try to control the narrative". Gas light city.
I wasn't referring to package benchmarks, my apologies if that was unclear.
I'm glad I'm not the only one that feels this way. I love Julia as a language (not as an implementation, which is a pain-in-the-ass to work with), but there has long been a pattern of responses which in practice amount to gaslighting. Afaik it's only small set of people who do that, and charitably they're likely just being less-than-thoughtful about generalizing their "work for my project", "works on my 24 core computer", "works when I know half the people developing packages" experiences to everyone. But to an outsider, it looks like the answer is always "the problems are all fixed now, you're just out of date", and most of the time that turns out not to be true.
More than half the community feels that way the other half are either sycophants or don't care. It's not like it's one person either, it's the language maintainers general attitude. It's been called out in the past but it sure hasn't changed because there's a product to sell.
Your benchmarks are not concrete and realistic. I have never seen any language but (unsurprisingly) Julia, to compare its performance with the performance of other languages by calling those languages from within the host language. Definitely 15000 times faster than MATLAB as claimed by JuliaComputing can be achieved with such seemingly concrete and realistic benchmarks.
LLVM has benefited and learned so much from Fortran and its compilers. But free food and service are always undervalued.
> Definitely 15000 times faster than MATLAB as claimed by JuliaComputing can be achieved with such seemingly concrete and realistic benchmarks.
I believe you're talking about NASA Launch Services engineers claiming Julia's ModelingToolkit simulations outperformed Simulink by 15,000x? That claim was of course not made by Julia Computing or anyone affiliated by Julia Computing, which is pretty clear because the person who makes the claim very clearly describes his affiliation at the beginning of the video. The source is here: https://www.youtube.com/watch?v=tQpqsmwlfY0, at 12:55. You did watch the whole video to understand the application and the caveats etc. instead of just reading the headline and immediately coming to a conclusion, right?
It is not just about call overhead. It is about a whole suite of aggressive optimizations only possible for a whole program. Point to one person or entity in the world who calls SUNDIALS Julia wrapper to bind their C production code to SUNDIALS. If you cannot, you have two options: 1. make your Julia benchmarks concrete and realistic or 2. cease and desist from pointless advocacy of your employer (JuliaComputing) and its benchmarks in public forums.
Sure you can keep moving goal posts. Of course it doesn't make sense to bind a C production code to a C package (SUNDIALS) through Julia. But if you're asking who is using Julia bindings to SUNDIALS as part of a real case, one case that comes to mind is the Sienna power systems dynamics stuff out of NREL (https://www.nrel.gov/analysis/sienna.html). If you look inside of the dynamics part of Sienna you can clearly see IDA being used (https://github.com/NREL-Sienna/PowerSimulationsDynamics.jl). IIRC at a recent Julia meetup in the Benelux region kite model simulations also used it for the same reasons (https://github.com/aenarete/KiteSimulators.jl) which of course is pointing to the open source code organization for Aenarete (http://aenarete.eu/).
The way to find other use cases is to look through the citations. Generally there will be a pattern to it. For cases which reduce to (mass matrix) ODEs FBDF generally (but not always) outperforms CVODE's BDF these days, so those cases have mostly converted over to using the pure Julia solvers. This includes not just ODEs but also other DAEs which are defined through ModelingToolkit, as the index reduction process generates ODEs and generally the ODE form ends up more efficient than using the original DAE form (though not always of course). It's in the fully implicit DAE form that the documentation (as of May 1st 2023, starting somewhere back in 2017 according to the historical docs) recommends using Sundials' IDA as the most efficient method for that case (https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/) (yes, the docs recommend non-Julia solvers when appropriate. There's more than a few of such recommendations in the documentation). Power systems is such a case with Index-1 DAEs written in the fully implicit form which are difficult in many instances to write in mass matrix form and not already written in ModelingToolkit, hence its use of IDA here. By the same reasoning you can also search around in the citations for other use cases of IDA.
Our discussion will continue as long as one side believes fair, realistic benchmarks are merely moving the goalposts. Your benchmark has a severe fundamental flaw, especially given the tiny reported runtimes. I hope you realize and fix it before other critics (perhaps more credible than an unknown forum contributor) begin to question your programming knowledge or fairness.
To address the matter, you must compile/write whole programs in each of the respective languages to enable full compiler/interpreter optimizations. If you use special routines (BLAS/LAPACK, ...), use them everywhere as the respective community does. Apples to Apples.
What about the other benchmarks on the same site? https://docs.sciml.ai/SciMLBenchmarksOutput/stable/Bio/BCR/ BCR takes about a hundred seconds and is pretty indicative of systems biological models, coming from 1122 ODEs with 24388 terms that describe a stiff chemical reaction network modeling the BCR signaling network from Barua et al. Or the discrete diffusion models https://docs.sciml.ai/SciMLBenchmarksOutput/stable/Jumps/Dif... which are the justification behind the claims in https://www.biorxiv.org/content/10.1101/2022.07.30.502135v1 that the O(1) scaling methods scale better than O(log n) scaling for large enough models? There's lots of benchmarks on that site which show things from small to large. And small models do matter too...
> If you use special routines (BLAS/LAPACK, ...), use them everywhere as the respective community does.
It tests with and with BLAS/LAPACK (which isn't always helpful, which of course you'd see from the benchmarks if you read them). One of the key differences of course though is that there are some pure Julia tools like https://github.com/JuliaLinearAlgebra/RecursiveFactorization... which outperform the respective OpenBLAS/MKL equivalent in many scenarios, and that's one noted factor for the performance boost (and is not trivial to wrap into the interface of the other solvers, so it's not done). There are other benchmarks showing that it's not apples to apples and is instead conservative in many cases, for example https://github.com/SciML/SciPyDiffEq.jl#measuring-overhead showing the SciPyDiffEq handling with the Julia JIT optimizations gives a lower overhead than direct SciPy+Numba, so we use the lower overhead numbers in https://docs.sciml.ai/SciMLBenchmarksOutput/stable/MultiLang....
> you must compile/write whole programs in each of the respective languages to enable full compiler/interpreter optimizations
You do realize that a .so has lower overhead to call from a JIT compiled language than from a static compiled language like C because you can optimize away some of the bindings at the runtime right? https://github.com/dyu/ffi-overhead is a measurement of that, and you see LuaJIT and Julia as faster than C and Fortran here. This shouldn't be surprising because it's pretty clear how that works?
I mean yes, someone can always ask for more benchmarks, but now we have a site that's auto updating tons and tons of ODE benchmarks with ODE systems ranging from size 2 to the thousands, with as many things as we can wrap in as many scenarios as we can wrap. And we don't even "win" all of our benchmarks because unlike for you, these benchmarks aren't for winning but for tracking development (somehow for Hacker News folks they ignore the utility part and go straight to language wars...).
If you have a concrete change you think can improve the benchmarks, then please share it at https://github.com/SciML/SciMLBenchmarks.jl. We'll be happy to make and maintain another.
They are one time per instance. Which isn't the same thing as one time. Julia sysimages are huge and take a long time to generate even on decent hardware. Last I checked that whole process was very janky, poorly documented, and under heavy revision(as it had been for years prior).
it's not. once you generate it somewhere you can just copy the files to anywhere that has the same architecture.
sysimages are huge (but they've gotten a decent bit smaller recently). notably, 1.8 added some features that let you make them a bunch smaller for deployment. you can now remove the metadata (i.e source code text) which saves about 20%, and you can also generate it from a Julia launched with -g0 to remove debug info (Julia unlike C includes debug info by default because stack traces are nice). we also recently fixed a really dumb bug that was causing libraries to be duplicated in sysimages, so that will sometimes save a few dozen mb. (who knew that tar duplicates symlinks?)
When did you last check? it's now pretty dejankified and has been for about a year. the docs aren't perfect, but I think they're relatively good.
People have been saying "it's better" for 3 years now. One things for sure, I'm not going to go recheck this again, anytime soon. Anything I'll say at this point will be met with "it's better now" and then I'll have to go find out it's really not in classic Julia fashion. The docs for package compiler were awful for about 2 years. See my above comment and other users jumping as to how annoying it is.
Fun Julia story. I remember one time someone, I believe from Julia computing(iirc) was telling me how much better Julia had gotten at something. They sent me links to academic flag plant repositories that had no code in them. Literally empty packages with no branches even with statement of purposes readmes. I offered to work on it and was met with... Academic competition about how I shouldn't do that because a package already existed for it, and how I should try to work with the author on theirs. Meanwhile I already had code for it, it just never went into the ecosystem. I'm highly unlikely to start investigating Julia again in the short term. Maybe in five years.
The reason people have been saying it's gettting better for 3 years is because it has been. PackageCompiler 1.0 was released in 2020 which made it possible to distribute Julia programs as self contained apps, Julia 1.6 released in 2021 added parallel precompilation which made loading a lot faster. Julia 1.8 was released in 2022 which improved precompilation a bunch, and Julia 1.9 will be released in 1 to 2 weeks and makes precompilation cache native code which significantly improves things again.
Deployment is a fundamentally hard problem for dynamically typed languages. Shipping a Julia .so will probably never be as easy as shipping a .jar file in java. However, Julia has gotten a lot more deployable over the past 3 or so years and work on that front continues. Julia 1.10 already has a bunch of compiler speedups that make things a bunch faster than 1.9 (I expect 1.10 to ship late 2023 or early 2024)
Your parent comment wrote "it's better", you said "it's getting better". This is a common Motte-and-bailey argument in Julia discussions:
The "it's better [now]" is most often given as a response to someone expressing a problem they've had, and in context it's presented in a way that suggests the problem is fixed.
"It's getting better" is a far more reasonable response, if it also comes with a caveat about how much better it's gotten and how usable for purpose it is. A lot of the time Julians seem to conflate between "it's a reliable usable feature" and "a pull request vaguely related has been merged and will be available some time in the future, which fixes maybe 10% of the issue".
If you reread this comment thread under the guise of "hm how is the Julia community?". I think you'd find it very enlightening. Maybe even find things you could improve. If only that was the goal.
Neither Julia nor Matlab are great production languages. They are both fine if you just have some math you want to run to get some results. But... Julia changes and breaks core functionality regularly in pretty much everything from the language itself to the packages you use. Matlab although is more stable, has other detriments. It's closed source, it's not really designed to be a systems language, sometimes it's not fast enough, etc.
In my mind, fortran will always be hard to replace especially if there is sizeable legacy code. A lot of people don't realize it, but fortran is kind of like sql. It's old, backed by a lot of theory, and delivered on it's promises for years. That makes challengers job really really hard.
At this point, Julia is being used on ASML's lithography machines. it's pretty deployable.
I'm not sure where you are getting the idea of frequent breaking releases. the language has been pretty stable since 1.0 in 2018 (as in almost all code that worked on 1.0 still works now). (there are some very minor breaking changes in minor releases, but Julia breaks a lot less things per release than python or C).
Cool I am glad there are more people using it in production these days, it will help the language become more stable. I've deployed Julia to production a few times now. In almost every case it was rewritten in another language within a year for one reason or another... This is sad, but, for being a v1 language, it never lost it's "early adopter" experience for myself or my colleagues.
I've seen minor releases in Julia break essential packages. Not like it was one time either. So where did I get the idea, personal hands on experience.
Again it's great if you have a script and want to run it, anything beyond that, in my experience, results in a lot of turmoil and erosion. Almost wonder if it's a flaw in the language itself or, the maintenance model of the packages. Oh well not my problem
Absolutely, a minor change to Julia base broke the CSV package for weeks. But that's like 1 of hundreds of examples. I don't think non package developers realize how much effort package maintainers and drive-by contributors do to keep that language alive.
Would you happen to remember the specific version, or links to any of the other examples? I ask because I've repeatedly heard that every release is tested against the entirety of the (public) package ecosystem, so I'm curious how these snuck through - whether it was before such a system was put in place (maybe because of these breakages), or whether things still sneak through the tests to such a degree.
I don't remember, maybe check closed issues in their repository. But I think we all know why you're really saying this. To cast doubt on what I'm saying. That's okay, gotta get that $$$ or something.
> Does Fortran still have any real advantage over Julia, MATLAB, etc.?
These are incomparable since Fortran is a standardized programming language with multiple implementations, whereas the other two you mentioned are products having single implementations.
The new revisions of Fortran are actually quite nice to work with. I had a month of using fortran in a company I worked in and reworked some Fortran 70 code into a more recent version (Fortran 2000?).
It overall felt more high level than plain C. Eventually I also ported the code to Python and Cython and while the cython implementation actually was more performant (arrays were always allocated with fixed sizes in Fortran and in python it was easy to pick just the right sizes), the Fortran implementation was fairly readable
Probably as long as most nuclear software (codes) are written in mostly Fortran. It is not that difficult to learn Fortran. Some "Codes" require a mixing C and Fortran during the object linking process. Most of the times the intel Fortran compiler is preferred.
as a mechanical engineer i wrote lots of FEM codes in FORTRAN, i still do and honestly enjoy programming in it. the lack of graduates who know Fortran is a correct estimate. As far as I know, it is usually replaced by MATLAB and Python in our departments. Unfortunately, C++ is taught less.
i don't know much about future CPU technology or why it is likely that Fortran codes don't perform properly on GPU. but i know that NVIDIA takes too much time to provide CUDA-FORTRAN for windows. nothing happened after 4 years.
But it seems to me that the isolated Fortran programmers have recently become well connected. Look at the website [1], Package Manager or LFortran [2].
[1] https://fortran-lang.org/en/
[2] https://lfortran.org/
I don't think "survive" is the right word. There are so many fields where orgs have tried and failed to replace Fortran. Maybe they have not tried as hard as they could, but the conversation was there. Why would they suddenly want to get this done, no expenses spared?
Fortran is a fine programming language. It's very simple, very performant, and very portable.
I personally prefer using Julia, but I think people are pretty ignorant about the modern state of Fortran when they act like it's some unusable crappy relic with no point in using it.
Staffing will remain the the biggest challenge. Attracting scientists and mathematicians who understand the problem domain of what this body of Fortran represents is critical. These persons will either lead continued development in Fortran or oversee the AI conversion onto another platform.
Fortran is simpler to learn than C++, and much simpler to learn than the applied mathematics that the programs embody. Just make sure the Fortran code is confined to applications it's good at (maths, not IO or data shuffling) and people will be happy to learn on the job. I was!
We have to train new staff in how to do C++ programming now. Fortran is much easier to explain than C++. As soon as people go from toy problems to big compute they will face the same problems that led to solutions like Fortran.
What we might see is Fortran being generated from higher level specifications, particularly distributed parallel computations using task specific processors.
One perhaps large remaining area of Fortran code is the seismic processing industry for oil and gas exploration. 15 years there seems a plausible timeframe for the industry to shrink a lot, though there still might be some work for production monitoring.
> The cost of the compiler technology—which translates a program into machine code to run on high-performance systems—is rising, with recent estimates of tens of millions of dollars.
for fortran, the intel one (ifort) generally produces much faster binaries. The NAG compiler is known for having great warnings / quality control and pushes you to write better code. Both are available for windows compilation. I do not know the others, but GCC is very good if you do nothing performance critical (but then again you're writing fortran...), you want good but not great checks, and you do not need windows binaries.
Everyone I met who writes fortran (mainly for quantum chemistry, solid state physics programs) uses multiple compilers to ensure the highest quality code.
I have not yet seen anything like this, but I have observed the Intel compiler produce different bytecode on Intel and AMD machines.
In one case, the compiler would use masking vector instructions on Intel but not on AMD. It was also the correct decision: Those instructions have very low latency on Intel, but are many times slower on AMD. On each platform, it produced the best bytecode that it could.
Yes, there is a Nvidia/PGI compiler for compiling Fortran to CUDA, and lets you use all the Cu libraries (CuBLAS, CuFFT etc.) from your Fortran code
https://developer.nvidia.com/cuda-fortran
As for the question in the title, yes Fortran will be around in 15 years. Perhaps the share of Fortran in new developments is shrinking, but more due to Python, Julia, MATLAB and such, and not C++.