Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Resurrecting Fortran

ondrejcertik.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Resurrecting Fortran

#11

Post by hpcjoe »

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.

Re: Resurrecting Fortran

#12

Post by precsim »

certik wrote: post #8
yodelshady wrote: post #4

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. Th…

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?

Re: Resurrecting Fortran

#13

Post by precsim »

andi999 wrote: post #5

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)

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.

Re: Resurrecting Fortran

#15

Post by onei »

yodelshady wrote: post #4

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. Th…

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

Re: Resurrecting Fortran

#16

Post by wrycoder »

GnarfGnarf wrote: post #2

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.

Re: Resurrecting Fortran

#17

Post by throwawayboise »

hpcjoe wrote: post #11

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…

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.)

Re: Resurrecting Fortran

#18

Post by the_only_law »

throwawayboise wrote: post #17
hpcjoe wrote: post #11

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…

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.

Re: Resurrecting Fortran

#19

Post by gnufx »

precsim wrote: post #13
andi999 wrote: post #5

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)

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.]

Re: Resurrecting Fortran

#20

Post by gnufx »

andi999 wrote: post #5

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)

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.)
Post reply on HN