Can Fortran survive another 15 years?
gcn.com
gcn.com
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++.
[0]: https://permalink.lanl.gov/object/tr?what=info:lanl-repo/lar...
[1]: you can hire me if needed ;-)
DEC was bought by Intel which meant that license fees were required to keep the tool alive.
However, some intrepid nerds contributed a patch to GCC and, suddenly, life went on without Intel. I want to say that this was around GCC 6.x or so.
Which is how to cut at least that portion of the costs for the balance of these classic tools.
Their compiler business was bought by Intel, DEC itself was bought by Compaq.
No, it wasn't.
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 other big thing HP got was DEC's minicomputer OS, VMS. It killed it, as I wrote at the time: https://www.theregister.com/2013/06/10/openvms_death_notice/
But it changed its mind and spun it off instead.
Between Cuda Fortran, OpenAcc, and OpenMP, this argument is more than weak.
"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."
Or is NVIDIA's Fortran version not robust?
Fortran is better at arrays than C++ and most other languages, which makes it better on GPUs too.
> 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.
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.
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 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.
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.
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.
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)
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".
> A lot of Julia's public benchmarks are not idiomatic Julia or packages were created to elide how nonidiomatic they are.
??? https://docs.sciml.ai/SciMLBenchmarksOutput/stable/MultiLang... this is pretty standard code.
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).
I wasn't referring to package benchmarks, my apologies if that was unclear.
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.
> 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.
You must be a truly special kind of stupid to be questioning Chris' knowledge.
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?
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.
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).
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
Any specific examples of this happening in Julia 1.0 or later?
See the HOPL history for the background of MATLAB: https://dl.acm.org/doi/10.1145/3386331
EDIT: fixed paper link
These are incomparable since Fortran is a standardized programming language with multiple implementations, whereas the other two you mentioned are products having single implementations.
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.
What we might see is Fortran being generated from higher level specifications, particularly distributed parallel computations using task specific processors.
Really? What have they got that GCC can't munch?
Everyone I met who writes fortran (mainly for quantum chemistry, solid state physics programs) uses multiple compilers to ensure the highest quality code.
Unless you happen to have a AMD processor, then the Intel compiler will go out of its way to cripple performance. See https://news.ycombinator.com/item?id=30935064
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.