[HN Gopher] Resurrecting Fortran
___________________________________________________________________
Resurrecting Fortran
Author : yomritoyj
Score : 91 points
Date : 2021-03-13 09:57 UTC (13 hours ago)
(HTM) web link (ondrejcertik.com)
(TXT) w3m dump (ondrejcertik.com)
| GnarfGnarf wrote:
| My first language, 1965, on a CDC 3100. We used Eliot Organick`s
| text book. Wonderful memories.
| wrycoder wrote:
| 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.
| gnufx wrote:
| 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.
| enriquto wrote:
| 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.
| certik wrote:
| 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.
| goerz wrote:
| "Rejuvenating Fortran" would have been a better title ;-)
| certik wrote:
| Next time. ;)
| yodelshady wrote:
| 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'.
| certik wrote:
| 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.
| precsim wrote:
| Very interested in LFortran, are there any benchmarks how it
| compares with respect to performance to GFortran or Intel
| Fortran?
| certik wrote:
| 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
| onei wrote:
| Why do you think the Rust version was so much slower to
| produce?
| marmaduke wrote:
| Rosetta 2 provides really good performance so you can just run
| your regular x86 toolchain and executables on it until there's
| native support.
| eschaton wrote:
| How does LFortran compare to flang?
| certik wrote:
| 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.
| andi999 wrote:
| 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)
| precsim wrote:
| 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.
| gnufx wrote:
| 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.]
| certik wrote:
| 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.
| gnufx wrote:
| 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.)
| certik wrote:
| 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.
| hpcjoe wrote:
| 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.
| throwawayboise wrote:
| 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.)
| the_only_law wrote:
| I recall reading on HN a while back that a modern z/OS
| mainframe can run unmodified System/360 binaries.
| 1996 wrote:
| wine can also run unmodified windows binaries
| gnufx wrote:
| 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.
___________________________________________________________________
(page generated 2021-03-13 23:02 UTC)