Fortran Standard Library

Re:Fortran Standard Library by ojnabieoot on Wednesday May 13, 2020 @05:19PM (#23171952)

I have not kept up with recent developments, but Fortran has historically been noticeably faster than even C/C++ for numerical computations. This difference used to be quite stark due to limitations in C itself: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html (see " b) The design of FORTRAN allows maximal speed of execution:") I think things have gotten better in C, e.g. with C99's "restrict" keyword, along with general improvements in C compilers, but for a long while Fortran had a clear upper hand when it came to allocating and manipulating large arrays of floats. Outside of the language specification, I would wager that many supercomputers have better-optimized Fortran compilers than C compilers for this reason. And even if in principle C and Fortran can execute equally performant numeric code, Fortran's historic superiority has created a great deal of high-quality legacy Fortran code that nobody feels an urgent need to port into C (which would be tedious, expensive, and risky work).

In the modern day: R uses a standard Fortran BLAS implementation, as do many other libraries and platforms (NumPy, Numerics.NET, etc). LAPACK is also widely used for low-level numerical linear algebra: https://github.com/Reference-LAPACK/lapack Intel also maintains a BLAS implementation. So there's still a healthy need for a (small) community of Fortran programmers, it's not all about maintaining 70s legacy code. Very different than the situation with COBOL.

[ Parent | on HN ]

Re:Fortran Standard Library by gnufx on Wednesday May 13, 2020 @06:05PM (#23172366)

Aspects of Fortran favour it over C even when restrict is used, e.g. as mentioned in https://news.ycombinator.com/item?id=23124451

[ Parent | on HN ]

Re:Fortran Standard Library by gnufx on Wednesday May 13, 2020 @05:58PM (#23172316)

If you use the reference BLAS routines that ship with R, you're losing an order of magnitude serial performance on relevant operations. (The majority of Intel MKL surely isn't written in Fortran, like OpenBLAS and BLIS.)

[ Parent | on HN ]

Re:Fortran Standard Library by jjdredd on Wednesday May 13, 2020 @07:31PM (#23173124)

> Fortran has historically been noticeably faster than even C/C++ for numerical computations

Nowadays: faster - maybe, noticeably - I doubt it.

> supercomputers have better-optimized Fortran compilers than C compilers

I don't know about supercomputer compilers but mainstream compilers usually have the same backend for FORTRAN and C (as well as other implemented languages).

> created a great deal of high-quality legacy Fortran code that nobody feels an urgent need to port into C

Optimized and tested FORTRAN code - maybe, but not high-quality. I've seen some of it, FORTRAN makes it difficult to write readable, maintainable code. For this reason even scientist are rewriting their tools and libraries (that also require good performance) in C++: for example see Pythia, GEANT, cern root.

[ Parent | on HN ]

Re:Fortran Standard Library by neurostimulant on Wednesday May 13, 2020 @08:53PM (#23173852)

The thing is, you can write a perfectly normal fortran code, and instantly gain speedup (CUDA, distributed computing with OpenMP, etc) just by enabling some compiler flags. You can't do this in C/C++ as you have to deliberately write your program to use those tech. Also, vector/matrix operations are first class in fortran and you don't need to rely on 3rd party libs.

[ Parent | on HN ]

Re:Fortran Standard Library by jjdredd on Wednesday May 13, 2020 @10:32PM (#23174589)

> The thing is, you can write a perfectly normal fortran code, and instantly gain speedup (CUDA, distributed computing with OpenMP, etc) just by enabling some compiler flags.

I'm not sure I understand you correctly. Can you give examples of such flags?

> Also, vector/matrix operations are first class in fortran and you don't need to rely on 3rd party libs.

It may be useful as long as you're hell-bent on not using libraries (which is somewhat contrary to one of the pro-FORTRAN arguments that FORTRAN has lots of libraries that are tested and ready to use).

This is a weak consolation though, since anything complex enough deals with custom matrix/vector types for sparse matrices or data types used in parallel computations.

[ Parent | on HN ]

Re:Fortran Standard Library by neurostimulant on Thursday May 14, 2020 @11:26AM (#23180673)

Not sure about gfortran, but commercial fortran compilers supports automatic parallelization (e.g. intel fortran compiler -parallel flag [1]). You can even go as far as parallelizing you program across a cluster of machines via OpenMP by simply sprinkling some directive in your program to mark the code that must be parallelized via OpenMP. I remembered incorrectly about cuda. PGI fortran compiler supports CUDA but you still need to deliberately use it in your code, though there are projects that attempt to make this automatic (not sure if they're really took off).

> It may be useful as long as you're hell-bent on not using libraries (which is somewhat contrary to one of the pro-FORTRAN arguments that FORTRAN has lots of libraries that are tested and ready to use).

Yes, library is still used but it's typically only for data input/output. For example NetCDF is a popular data format and many fortran projects support the format via 3rd party library. But for complex matrix computation, this is essentially what fortran was made for so it's not typical to use 3rd party library for this. Most big fortran projects in the area I was involved with (meteorology and air pollution) uses minimal amount of 3rd party library and mostly rely on built-in fortran functionality, with optimization being left to the compiler (typically intel or pgi fortran). There is definitely code reuse, but it's in the form of the scientist collecting snippets of useful algorithm over the years and copy it to the project when they needed.

[1] https://software.intel.com/content/www/us/en/develop/documen...

[ Parent | on HN ]

Re:Fortran Standard Library by jjdredd on Thursday May 14, 2020 @03:16PM (#23184064)

That's very cool but it's in no way specific to the FORTRAN language:

https://software.intel.com/content/www/us/en/develop/documen...

contrary to the earlier comment:

> You can't do this in C/C++

On a side note: having (semi)automatic parallelization with code generation for GPGPU would be very nice.

> There is definitely code reuse, but it's in the form of the scientist collecting snippets of useful algorithm over the years and copy it to the project when they needed.

I think that's just bad programming practices.

[ Parent | on HN ]

Re:Fortran Standard Library by neurostimulant on Thursday May 14, 2020 @03:55PM (#23184538)

Well, doing complex matrix calculation yourself in C/C++ without 3rd party library is hard. Unless you write everything yourself or specifically use intel MKL library, the benefit of enabling automatic parallelization on C/C++ won't be as impactful as in fortran where it's common do all calculation without using any 3rd party math library.

[ Parent | on HN ]

Re:Fortran Standard Library by walshemj on Wednesday May 13, 2020 @08:04PM (#23173419)

Not Shure that using c++ is going to help with "readable, maintainable code" any more than modern Fortran is.

and I suspect they will be writing Fortran in C++

[ Parent | on HN ]

Re:Fortran Standard Library by jjdredd on Wednesday May 13, 2020 @10:25PM (#23174544)

Could be, at least C++ has tools to implement better design. I've seen one guy's python code that looks worse than his FORTRAN code. There's a russian saying: "A true FORTRAN programmer can write FORTRAN code in any language".

[ Parent | on HN ]

Re:Fortran Standard Library by greglindahl on Thursday May 14, 2020 @12:04AM (#23175147)

Are you sure you aren't being polluted by this article? https://www.pbm.com/~lindahl/real.programmers.html

> Besides, the determined Real Programmer can write Fortran programs in any language.

[ Parent | on HN ]

Re:Fortran Standard Library by walshemj on Thursday May 14, 2020 @06:04PM (#23186140)

Heh I have worked on Nuke simulations for a breeder reactor so a mommy bomb and I have written Billing systems in Fortran.

And that billing system was very well designed using map reduce back in the early 80's, we did have an actual genius as a team leader though.

[ Parent | on HN ]

Re:Fortran Standard Library by jjdredd on Thursday May 14, 2020 @01:35AM (#23175726)

Heh, I could have made a mistake about the origin of the saying. I haven't read that article.

[ Parent | on HN ]

Re:Fortran Standard Library by greglindahl on Thursday May 14, 2020 @12:02AM (#23175135)

One fun way to evaluate potential applicants for working on a C/C++/Fortran compiler backend is to ask them about Fortran. If they say that they appreciate how it makes it easier to optimize things, then you're probably talking to an experienced engineer.

[ Parent | on HN ]