Resurrecting Fortran | Hacker News Reader

Resurrecting Fortran

ondrejcertik.com

116 pointsyomritoyj36 comments

I've been a Fortran user for (gawd help me) 35 years or so. I can say that rumors of its demise are greatly exaggerated.

There are many languages, and language fads. Fortran was never sexy, never faddy.

My research codes from 30+ years ago still compile w/o issue to this day, and run, on my linux laptop. Even using the big endian data files (gfortran has a nice switch for that).

I don't really use it actively anymore. But I know many who do. And when I hear others say "X for scientific computing", I've got to chuckle a bit. C++ code I wrote 15 years ago won't compile today. Python ... the language changes within minor versions (ran into this at work last week, with 3.6.8 being sufficiently different than 3.9.x that I had to rewrite a number of functions for 3.9.x).

I've not had to change my Fortran. Or my 25+ year old Perl. They just work. Which is something of a base requirement for scientific code. If you hand someone a code base, and N months/years later, it doesn't work ... that helps no one.

COBOL is another one. COBOL programs written decades ago are still running unchanged on mainframes today. (Not that it was ever used for scientific computing.)

I recall reading on HN a while back that a modern z/OS mainframe can run unmodified System/360 binaries.

Well, there was the shocking news here not long ago that some OS\360(?) backwards compatibility had been dropped. What's the world coming to.

Relevant to Fortran, there's a version of ESSL that I recall on OS\370 now for POWER9 (and doubtless 10). Scientific subroutine libraries are arguably the best example of the re-use beloved of those who haven't seen their OOP code last decades.

wine can also run unmodified windows binaries

Yes and if those windows binaries were from a platform from over 50 years ago then perhaps your snarky quips would come off as intelligent.

Windows 3.1, released on April 6, 1992 - so only 29 years old.

My bad, the 21 years difference must be important (somehow?)

> C++ code I wrote 15 years ago won't compile today

Do you recall specifically why?

Also, isn't C pretty 'time proof'? The only time I've seen old C fail to compile was when dealing with a real relic of a codebase. If memory serves it used the pre-standardisation parameter-declaration syntax:

    void my_func(x, y)
    {
        int x;
        long y;
    }

It's perhaps worth saaying that 30 years ago code in the wild might well not have compiled and run correctly on a different system, and is more likely to today. There tended to be more non-standard features and ignoring of the standard -- specifically storage association and order of evaluation rules, which people who hadn't read the standard would swear weren't in it. Also, there are a few things which have been dropped from the standard, though not necessarily from compilers.

I don't really like the title of this post, due to its implications... you can only resurrect something that is dead. But Fortran is alive and kicking. It is a fundamental language of our technological infrastucture. Millions of people run algorithms every day that are implemented in Fortran! It is also one of the few languages where you can reliably implement numerical algorithms and reason about their efficiency and memory usage.

Author here. Yes, some people did not like the title, I didn't realize that it necessary means Fortran was dead. I meant it in the way of "rejuvenate". Fortran was not dead.

“Rejuvenating Fortran” would have been a better title ;-)

Next time. ;)

Fortran's the only obstacle to purchasing M1 for me currently.

A while ago I compared the execution time for some simple matrix arithmetic in rust, fortran (2003 I think), and python/numpy. (as an aside: as far as science is concerned, python without numpy doesn't exist.) Execution times were fairly similar.

What I didn't mention was the pretty-much-optimal fortran and python solutions took maybe a minute to code.

The optimal Rust solution took over a day.

I'll also note intent(in), intent(out) fulfil similar uses to '&' and '&mut'.

Rosetta 2 provides really good performance so you can just run your regular x86 toolchain and executables on it until there’s native support.

LFortran is not ready yet for production usage, but I've been developing it on M1 Macs, everything works (both compiling of LFortran itself, as well as LFortran compiling other codes and interactive usage in Jupyter). It compiles really fast and I really enjoy the experience of M1.

Very interested in LFortran, are there any benchmarks how it compares with respect to performance to GFortran or Intel Fortran?

There is speed of compilation (I did some very preliminary benchmarks and I think it will be very good) and there is speed of the generated code, there currently we just use stock LLVM. But down the road we will have special optimizations on top, just like Intel Fortran is doing. Some of the things I personally would like to have a close look on is array operations, where I've heard from many users that they are slower than explicit loops. And function inlining and other such operations.

We want to have a dedicated repository for benchmarking compilers:

https://github.com/fortran-lang/benchmarks/issues/2

Why do you think the Rust version was so much slower to produce?

My first language, 1965, on a CDC 3100. We used Eliot Organick`s text book. Wonderful memories.

1964, IBM 1620, 1311 drive. McCracken text.

I remember the day the prof was late to class and came in looking much the worse for wear. The drive had experienced a head crash.

Thanks from those of us feeling relatively young for once, even if we have read McCracken.

The best failure I know was due to beer fermenting in the warm space above the fancy disk of an old Sigma 3; with hilarious consequences. No opportunity to get worse for wear from that batch, obviously.

How does LFortran compare to flang?

Author of the blog post here. There are two Flang compilers:

https://fortran-lang.org/compilers/

The legacy Flang and a new Flang. I don't know exactly the plans for the legacy Flang, but I assume the idea is to eventually use new Flang. The new Flang and LFortran where started at about the same time, they have a little bit different design. Both written in C++. LFortran has from the ground up written to be interactive (like Julia or Python), in addition to regular compilation to binaries. Some of the other goals of Flang and LFortran overlap.

I think it's good for Fortran to have at least two actively developed open source compilers.

> Quick Start: Variables, Example: variable assignment [1]....

> pi = 4.141592

Well, for the sake of a reasonable correctness in the code example. Must be a typo with the intended:

pi = 3.141592

Thanks for your efforts to help Fortran move forward.

[1]: https://fortran-lang.org/learn/quickstart/variables#declarin...

Good catch! Thank you:

https://github.com/fortran-lang/fortran-lang.org/pull/230

Several things surprised me, both in the blog post and the other comments. (Though hpcjoe's and enriquot's comments took care of the "What? Fortran is dead?" reaction.)

- (Comment) "array operations, ... are slower than explicit loops" May be related to the following:

- No mention of vectors.

- No mention of LINPACK, LAPACK, etc.

- No mention of GPUs.

Fortran arrays are indexed as you choose.

Vectors would be arrays. Array operations will lose if the compiler doesn't scalarization/deforestation properly (if deforestation is an appropriate word when dealing with arrays rather than lists/trees). Subroutines libraries and GPUs are irrelevant.

What stopped me a while ago was the availability of good free compilers. (the appeal is you could be faster than C for numerical code in Fortran, but I remember vaguely these compilers then would not be cheap)

Indeed. Intel Fortran is generally considered one of the best. It was not cheap, but it is now available for free. In general I think there is a huge opportunity for new compilers, and I have started one such effort myself: https://lfortran.org.

I often nowadays find GNU GFortran the same speed or faster than Intel Fortan for FEM/CFD codes, while 10-15 years ago Intel Fortan was 10-20% faster in general. So these days I typically just recommend to go with GFortan which is easily available on most platforms.

And not only on such codes. I've posted variations on this before:

In my experience GNU Fortran was always competitive with proprietary compilers at around the 20% level on average once the scheduling was sorted for a new architecture. That's from the times I could try SPARC SunOS and GNU/Linux, MIPS/Irix, Alpha/Tru64(?), RS6000/AIX, and x86 GNU/Linux. (I don't know about the times between those and Opteron.)

I don't have the numbers to hand, but it's at that level on the Polyhedron benchmarks relative to Ifort on SKX with roughly equivalent options. I think it was twice as fast on one case and basically only lost out badly where it unfortunately doesn't use vectorized maths routines for a couple of cases unusually dominated by them, whereas libvecm would be used for C. GNU Fortran is also surprisingly more reliable than Ifort, but has the bizarre mystique that had me ordered to use it against the advice of maintainers of the code, notwithstanding previous comparison with Ifort, and though the result crashed with the Ifort du jour -- which wasn't an immediate clincher.

I don't remember the numbers relative to XLF on POWER, but they were respectable, and I don't have access to the proprietary Arm compiler.

Anyhow, typical HPC run times are relatively insensitive to code generation compared with MPI (especially collectives), and typically aren't even reproducible below the 10% level. [Broad picture, mileage varies, measure and understand, etc.]

I've seen a similar change in recent years. 10 years ago Intel Fortran was usually faster, at least 20%. Good 20%. GFortran seems to have caught up a lot.

For anyone doing HPC work and hasn't tried GFortran >=10, I highly suggest giving it a go. We switched to it for the arm64 improvements, but surprisingly also found a 20% speedup on the x86-64 target. My best guess is that it's a combination of IPO and autovec enhancements.

Profiling and -fopt-info should tell you why. (If you care about speed, use them anyway!) I'd be surprised if it's vectorization improvements, other than a specific bug fix.

The main advantage usually quoted over C is the optimization opportunities from the storage association rules, in particular. GCC got the alias analysis for that as far back as the egcs version. (The flame war preceding egcs actually arose from the GNU maintainer refusing to incorporate the contributed patch for reasons I don't recall.)

Reply on news.ycombinator.com