15 ms·

Why physicists still use Fortran

205 points by urs 10y ago

dfgasfjhjhsdojj 10y ago
1. A program from 30 years ago will compile and run. 2. As a research student your first program is likely to be a F77 program written by your professor or an older colleague. 3. A library from 30 years ago can be easily wrapped into a modern program, compiled and run. 4. Arrays are really the most important thing for this sort of programming and since F90 array level operations have been baked into the language. 5. It is fairly trivial to write fast Fortran. 6. Fortran is much easier to use for numerical stuff than c++
ChuckMcM 10y ago
"Early Fortran (designated in allcaps as FORTRAN)" that would be because it is an acronym "FORmula TRANslator". Fortran continues to do that well. And as the article mentions scipy doesn't run as fast. The logical successor to Fortran was APL (Arithmetic Programming Language) but its notation really killed it. The properties that keep Fortran rolling (easy to start using, effective in translating formulas into computation) persist.
- thescribe 10y ago
  I'm ignorant about FORTRAN, have there been attempts to modernize it? Maybe something like coffeescript/typescript?
  - h4nkoslo 10y ago
    The latest major Fortran version, circa 2003, is at least as modern as something like C++.
    - bmh100 10y ago
      I would also like to add that there have been revisions in 2008 and 2015 [1]. [1]: http://fortranwiki.org/fortran/show/Fortran+2015 http://fortranwiki.org/fortran/show/Fortran+2015
  - an_d_rew 10y ago
    Fortran 2000 and beyond IS a very modern language.
  - ms013 10y ago
    You didn't read the article apparently. Fortran (which officially dropped all caps in the standard in 1990) has had new versions every couple years, up to 2013. Each revision of the language brings modern features into it, and old features go through a process of deprecation and then obsolescence. Most people seem to be unaware that it is an evolving language that has changed significantly since the standard most people are familiar with from 1977. I am a bit biased though: I work on a Fortran compiler, so I've had reason to stay on top of the standards as they come out.
    - thescribe 10y ago
      I misread that everything was backwards compatible, my bad.
  - mhd 10y ago
    In the 70s, when Fortran 66 still ruled the night, the usual suspects at Bell Labs wrote Ratfor, which was pretty much what Coffeescript did to Javascript, bending the syntax towards C. When you compare the current Fortran standards to its '66 version, you'll see how much progress it made. And I hope that you can actually use it these days. Round the turn of the millennium, it was still quite common for people to use Fortran 77 because that's all that was supported or fit in the general codebase.
- nikofeyn 10y ago
  APL is named after Kenneth Iverson's book "A Programming Language".
hcrisp 10y ago
FORTRAN may be faster but one graph shows Python recently overtaking it in mentions of Astronomy papers [0]. [0] https://mobile.twitter.com/astrofrog/status/787007261877166080 https://mobile.twitter.com/astrofrog/status/7870072618771660...
- arcanus 10y ago
  A great deal of that is for post-processing, however. Very little python used in the compute heavy pieces of scientific computation.
  - maus42 10y ago
    I know a person who works in atmospheric physics group. All the heavy physics simulation and modeling happens in Fortran, and then they do the "lighter" analysis, summary statistics, plots, visualizations, etc with a Python-based stack.
santaclaus 10y ago
What ever happened to the effort to bring Fortran to LLVM (from Los Alamos I think)?
- lightsighter 10y ago
  Still in development (paid for by LANL, done by PGI): https://developer.arm.com/-/media/developer/developers/hpc/files/ARM-HPC-UG-SC16-PGI.pdf?la=en https://developer.arm.com/-/media/developer/developers/hpc/f...
PaulHoule 10y ago
Even if you are using python, R or java you are still best off linking to matrix subroutines in fortran if you want to solve or diagonalize, get eigenvalues and such. This is not just about raw performance but also correctness, ecology of roundoff errors, etc.
- ricree 10y ago
  For Python, at least, the most popular numeric computation library (NumPy) uses a fair bit of Fortran under the hood. I'm not certain whether the matrix operations do, but it certainly wouldn't surprise me.
  - nerdponx 10y ago
    Doesn't NumPy just use BLAS and LAPACK for matrix operations?
    - ThatGeoGuy 10y ago
      The vast majority of BLAS and LAPACK are written in Fortran (at least, the ones provided by netlib.org). Github also reports that OpenBLAS is around 50% Fortran, so there's quite a bit there too [1]. Usually when you call BLAS functions from C you're really calling a cBLAS wrapper to some Fortran function. This is generally why you see -lgfortran -lf77blas when you compile programs that require numerical tools. [1] https://github.com/xianyi/OpenBLAS https://github.com/xianyi/OpenBLAS
      - simonster 10y ago
        At least in OpenBLAS, most (all?) of the BLAS routines are C functions that call kernels written in assembly, but many of the LAPACK routines are the Netlib reference Fortran versions.
- qznc 10y ago
  Yet, I root for D and its GLAS library [0]. It is a young project, but it beats the usual suspects for single-threaded matrix-multiplication. Stuff like "solve or diagonalize, get eigenvalues and such" is not written yet. It is very promising for a one-man project, though. We'll see in 10 years, I guess. Fortran certainly has a mythical reputation for performance, but it should be challenged every once in a while. [0] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
srean 10y ago
Guy Steele and his group had a really interesting thing going with the language Fortress (name is a nod to Fortran of course, but fortified). It was meant for high productivity as well as high speed (petaflops range). It got shelved after Oracle bought Sun. It was one of the three languages seeded by DARPA funding for high productivity computing https://java.net/projects/projectfortress/pages/Home https://java.net/projects/projectfortress/pages/Home https://blogs.oracle.com/projectfortress/entry/fortress_wrapping_up https://blogs.oracle.com/projectfortress/entry/fortress_wrap...
- nickpsecurity 10y ago
  Look up ParaSail. It's still in development that Im aware of.
- pjmlp 10y ago
  > It got shelved after Oracle bought Sun. Actually the actual real history is little more complex than that. JuliaCon 2016 (Keynote) | Fortress Features and Lessons Learned | Guy Steele https://www.youtube.com/watch?v=EZD3Scuv02g https://www.youtube.com/watch?v=EZD3Scuv02g It would be good if people on HN would separate a bit the Oracle hate with the facts.
  - srean 10y ago
    The causation was certainly not intentionally implied in my comment. I was stating temporal ordering fact. Hold on to your oracle defense response :)
spapas82 10y ago
One interesting fact that supports the point of the article is that Matlab is actually using the Fortran code for its implementation of special functions https://www.mathworks.com/matlabcentral/fileexchange/6218-computation-of-special-functions https://www.mathworks.com/matlabcentral/fileexchange/6218-co.... The amount of existing scientific code in Fortran is huge and there's a chicken and egg situation (new code uses/extends old code so new code will also be in Fortran) that will lead to further increasing it!
- spott 10y ago
  Matlab also uses MKL (written in fortran, with a heavy dose of assembler) for its blas routines I believe.
jstewartmobile 10y ago
It's funny that someone has to write an article to defend modern FORTRAN to people who write in JavaScript, which is the best proof we programmers have of entropy.
- taejavu 10y ago
  It's funny that in every discussion of programming languages that have nothing to do with Javascript, there's always some smug bastard bashing it.
  - jstewartmobile 10y ago
    Because it's really that bad, and we all have to use it because somehow, Brendan Eich's cocktail-napkin language became the VM of the web.
    - taejavu 10y ago
      Yes but if you go into a discussion of Star Trek movies complaining loudly about how bad you think the new Star Wars is, you're completely irrelevant at best.
    - andrepd 10y ago
      Yes, and what does that have to do with this article? If you come to a discussion about thing x to complain about thing y, no matter how valid your complaint you are out of order. To quote The Dude: "You're not wrong, you're just an asshole."
      - jstewartmobile 10y ago
        They're both languages. Just pointing out the irony of this guy taking the time to explain why Castro isn't such a bad guy to a world of Stalinists.
      - Annatar 10y ago
        Yes, and what does that have to do with this article? Excellent question, glad you asked! Just what do you think all the people who are asking why Fortran is still in use are using? My money is on the bet that they're not using Fortran. I've worked in the finite element analysis / high performance computing fields for quite a few years and I've never heard anyone who used Fortran complain that they were, or had to use it. Could it be that it's because people like that they get high performance from a language out of the box?
supergarfield 10y ago
> Interestingly, C/C++ beats Fortran on all but two of the benchmarks, although they are fairly close on most. Unless I missed something, this directly contradicts the quotes benchmark source[1], where C beat Fortran on all tests except one (where they were tied), and usually by a wide margin. Plus I believe gcc usually produces slower code than Intel's compilers (at least for C), so it's not clear that C-gcc and Fortran-Intel is a fair comparison. But beyond that, I'm always confused as to why there is a significant difference. I would expect two compiled languages with reasonable compilers to perform almost exactly the same when they're doing nothing but arithmetic operations, since those are almost entirely determined by the CPU, not the cleverness or speed of the standard library algorithms. Can anyone enlighten me? [1] https://benchmarksgame.alioth.debian.org/u64q/fortran.html https://benchmarksgame.alioth.debian.org/u64q/fortran.html
- santaclaus 10y ago
  > I would expect two compiled languages with reasonable compilers to perform almost exactly the same when they're doing nothing but arithmetic operations Auto-vectorization? These implementations vary wildly between GCC and Intel.
- jstewartmobile 10y ago
  Lies, damn lies, and benchmarks. I know as a long-time C programmer, there are small changes I can make to source that will result in big-time performance gains. Could hinge on how tight their FORTRAN code is vs their C code... Could also depend on how much love their respective machine code translations have been getting.
  - dfgasfjhjhsdojj 10y ago
    Fortran hasn't been all caps for nearly 30 years now... It is very easy for a physical scientist to write Fortran that performs well - the syntax looks very similar to the maths that is being modeled. It is a lot harder for a scientist to write tight C code.
    - 10y ago
pif 10y ago
> If a function that takes a ‘real’ is fed a ‘const real’, it will return an error. It is easy to imagine how this can lead to problems with interoperability between codes. What's he talking about? This is wrong!
syphilis2 10y ago
I've been looking for a Matlab alternative and been disappointed with either the performance or the syntax of Octave, Python, and Julia. I'd known Fortran had modern features and updates every few years, but never tried to pick it up since the excitement seems to be elsewhere. This article is convincing that Fortran is worth trying out.
- bmh100 10y ago
  If you want to get down into the nuts and bolts of numerical computation, with convenient concurrency, you should definitely look into Fortran + OpenMP.
- Xcelerate 10y ago
  What don't you like about Julia's syntax? Is it more than the 1-based indexing and "end" statements?
  - goatlover 10y ago
    Agreed, Julia syntax is very clean. Also, you can make it look more math-like with it's support for unicode variable and function names.
Animats 10y ago
Fortran is still better at multidimensional arrays. Other than Matlab, few other languages do multidimensional arrays at all. C-derived languages use arrays of arrays, and use templates, macros, or objects for multidimensional arrays. Fortran optimizers have lots of multidimensional array-oriented optimizations which other compilers usually lack. I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but slower representations so you could take arbitrary N-dimensional slices from a multidimensional array.
- ryescienceguy 10y ago
  > I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but slower representations so you could take arbitrary N-dimensional slices from a multidimensional array. This is the most frustrating aspect of Rust, to me, as a developer of scientific software. Rust has great potential to challenge Fortran in this domain, but numerics is mostly an afterthought in Rust.
  - throwaway7645 10y ago
    Agreed. I want to write numeric software, but don't want to use Fortran or C++. Rust looked great, but I couldn't find anything in this domain.
    - goatlover 10y ago
      Julia has strong numerical and multi-dimensional array support, but it's JIT compiled. However, once a function is JITted, it has comparable performance to Go & Rust.
      - divbit 10y ago
        Seconded for Julia. I have been using it for math prototyping and it's recently replaced my old favorites like matlab / python / lua.
troymc 10y ago
When I was doing my graduate studies in astrodynamics (spacecraft trajectory design) at Purdue University circa 2003, we worked closely with the Jet Propulsion Lab (JPL) and got to use a lot of their excellent astrodynamics code (used for missions like Galileo and Cassini). It was all Fortran. I heard that there was an effort at JPL to convert over to using Python. I'm not sure how that went. Maybe they were just writing Python bindings for their Fortran code? I know that much of SciPy consists of Python bindings for Fortran and C code [1]. The software I used to do "nonlinear programming" (i.e. parameter optimization), called NPOPT, was also written in Fortran. [1] https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fast-if-it-is-written-in-an-interpreted-language-like-python https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fas...
- mturmon 10y ago
  The Python replacement succeeded - I slightly know the people involved, who got an award for the work. But I don't use the library so I don't know if the wrapper approach was used. That would be perfectly legit IMHO.
bmh100 10y ago
Fortran is an excellent choice for numerical computation. Its non-aliasing assumption allows for compiler optimizations that dramatically speed up computations. It is even easy to get started with concurrent code through OpenMP. When I need to run a simulation or a discontinuous optimization algorithm, I turn to Fortran first. Here are some resources I have collected over the years. "Introduction to Modern Fortran" (Fortran 2003): http://people.ds.cam.ac.uk/nmm1/Fortran/index.html http://people.ds.cam.ac.uk/nmm1/Fortran/index.html Fortran Wiki: http://fortranwiki.org/fortran/show/HomePage http://fortranwiki.org/fortran/show/HomePage List of Fortran tutorials: http://www.fortran.com/the-fortran-company-homepage/fortran-tutorials/ http://www.fortran.com/the-fortran-company-homepage/fortran-... Fortran vs. C: http://www-cs-students.stanford.edu/~blynn/c/fortran.html http://www-cs-students.stanford.edu/~blynn/c/fortran.html Fortran's influence on C's "restrict" keyword: http://www.drdobbs.com/the-new-c-it-all-began-with-fortran/184401313 http://www.drdobbs.com/the-new-c-it-all-began-with-fortran/1...
- castratikron 10y ago
  To be fair, there are GCC built-ins that allow you to tell the compiler that arrays are nonaliasing, but you're right in that it's more difficult in general to get a compiler to spit out fast numeric code with C than it is with Fortran.
  - bmh100 10y ago
    I feel like it's a "right tool for the job" situation. Fortran was literally built for the purpose of numerical computation. Multi-dimensional arrays, non-aliasing arrays and pointers, multi-dimensional array intrinsics, intrinsic array binary operators... all come with Fortran right out of the box. Of course, C/C++ can do all of these things, but all of the proposed methods, at least that I have seen, feel like they are trying to hammer a screw.
- pmiller2 10y ago
  Glad this was posted. First thing I did on loading the comment section was ^F "alias". Fortran is still used for numerics because it makes writing fast numerical code easy. C simply wasn't designed for it, just as Fortran wasn't designed for low level system/OS programming.
davidf18 10y ago
It seems like a number of R packages use Fortran. I'm on Mac and it needs to Fortran compiler to be installed so that at least some of the R packages can be compiled when doing updates.
- bachmeier 10y ago
  R (the language, originally S) was created to be a "glue language" for compiled code, most of which was written in FORTRAN.
pducks32 10y ago
As a physicist please have faith in us. We don't all use Fortran. I use Ruby as much as possible and it's fun because it forces me to write libraries that mimic ones that are found in other languages. So I end up learning a lot.
- yxhuvud 10y ago
  I can recommend looking at Crystal if you have some time over. Very Ruby-like syntax, but compiles down to quite efficient native code.
- bmh100 10y ago
  How are you using Ruby for physics?
radioactivist 10y ago
The author is I think being a bit unfair to C++ when it comes to matrix/array handling. Their example of things that would be difficult to do in C/C++: A = B A = 3.24 * B C = A * B B = exp(A) norm = sqrt(sum(A * * 2)) Quoting: "Similar C/C++ code simply does not exist ... Having to use libraries instead of intrinsic functions means the resulting code is never as neat, as transferable, or as easy to learn." While this statement is true, I think strongly undersells how well these kinds of libraries can be "baked" into C++ through operator overloading, templating, etc. See for example, the Eigen library [http://eigen.tuxfamily.org/ http://eigen.tuxfamily.org/].
- deleted 10y ago
  [deleted]
- m_mueller 10y ago
  here's the problem: These kind of libraries will never come close touching Fortran's built-in features, simply because the compiler can't automatically optimise for knowledge about the code that only the library has. Even arrays not knowing their size is still an issue, let alone array based ops like shown in the article. Fortran is not the fastest language around the block, but if you don't want to go into non-portable machine-based hand-tuned optimisations (e.g. loop unrolling) it's hard to beat. Basically, if you optimise for both runtime and programmer time for HPC applications I'd argue that Fortran is top of the crop.
  - radioactivist 10y ago
    Well, in the case of Eigen it's an entirely header based library, so the compiler can optimize some things. Not to mention the template based meta-programming strategies [1] Eigen itself uses to simplify and optimize during compilation (including vectorization and loop unrolling). The fact that this kind of infrastructure can be built up in a library in C++, i.e. it doesn't have to be baked into the compiler, is a huge plus I think relative to Fortran. [1] https://eigen.tuxfamily.org/dox/TopicInsideEigenExample.html https://eigen.tuxfamily.org/dox/TopicInsideEigenExample.html
  - whyever 10y ago
spullara 10y ago
When I was in undergrad I did some computer simulation work for my professor. He programmed in FORTRAN while I had been trained in C/C++. I did my simulations in C/C++ and I also wrote some libraries for his FORTRAN code so he could have more dynamic configuration files. At the time I thought that FORTRAN was an anachronism and was surprised that it was still being used in physics. This was 1992.
Asooka 10y ago
I have one issue with the article. The way to dynamically allocate a multidimensional array in C is the following: size_t m, n; ... set m and n ... int (*a)[m][n]; a = (int(*)[m][n])malloc(sizeof(*a)); Edit: and you MUST NOT REUSE OR OTHERWISE CHANGE m and n FOR THE ENTIRE LIFETIME of the array, because bad things will happen. And you access it via (*a)[x][y] And you free it with free(a); And if you want to pass it to a function: void do_with_array(void* raw_array, size_t m, size_t n) { int (*array)[m][n] = (int(*)[m][n])raw_array; ... do whatever ... } do_with_array(a); And I'd rather do it in Fortran, but if you ever need to do it properly in C (i.e. without using array of pointers) - now you know.
- SFJulie 10y ago
  Technically you are right. Practically you are right, but the article is more right than you. I got into some fights with quite a few elite teachers/coders teaching the way of doing 2D arrays exactly as described, and they wouldn't agree the method you describe is less error prone ... because: it is tradition. (And as every person doing research know tradition is not supposed to change and that what science values). It seems absurd, but so many things are absurd these days I am not even surprised.
  - Asooka 10y ago
    Oh, the method I describe is more error prone than array of arrays, because if you ever modify the two variables you used to specify the array size, the compiler will just use the new values for array dimensions. If I had to do array of arrays though, I'd at least do something like template<typename T> T** make_2d_array(size_t m, size_t n) { // TODO: add padding for alignment, // but you're unlikely to need something aligned // on a larger extent than sizeof(void*) void *memory = malloc(m * sizeof(void*) + m * n * sizeof(T)); T** array = (T**)memory; T* data = (T*)((char*)memory + m * sizeof(void*)); for (size_t i = 0; i < m; i++) { array[i] = data + i * n; } return array; } And you can then delete the entire array with a single free().
- acqq 10y ago
  If I understand, your solution, as it is, would still be wrong to be passed to the Fortran code as in Fortran the column index is faster changing. And if you would blindly translate some FORTRAN code to C with the above arrays, even if you'd get the same results the C one would be slower because of that, as the FORTRAN code could have been written with the knowledge of which index arrangement is faster.
smegel 10y ago
> Note that Python, which is the darling of computer scientists Actually physical scientists love Python as much as they love Fortran. It a lot of cases, it is the only two languages they know.
SFJulie 10y ago
Just in case you want to use fortran code in python here is the scipy HOWTO Still up to date. https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-as-glue.html https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-a...
theden 10y ago
My reason for using fortran (when I was studying physics) was that when going through the university library looking for a computational physics textbook, I couldn't find one that wasn't in fortran—actually I found one (computational physics, Giordano & Nakanishi) but it wasn't enough to get by. Fortunately I already knew fortran, because all the legacy textbooks+journals were written in the language.
jheriko 10y ago
some of the information here is a bit wrong. the idea that const is weaker than parameter is true, but not for the reasons given. any function taking a float, int etc. in C++ can also take a const float or const int. its also unfair to suggest that C/C++ is as fault with not allowing a = b * c with array types. this is a failing of the standard library and easily fixed... operator overloading lets you create exactly this functionality, and std::valarray already does this for a lot of what you get in Fortran...
- pklausler 10y ago
  Good luck getting a high performance implementation of A=B+C without memory allocation out of a library.
  - jheriko 10y ago
    rolling your own is pretty easy, it is a shame that the C++ standard library is a dire wasteland of bad implementations. you are right that valarray will do heap allocations and making it work on the stack is a real ballache.
  - whyever 10y ago
    This is really not hard using expression templates.
hzhou321 10y ago
It is simply due to apprenticeship. Physicists do research, and their code is research code. Like most other research, the research code is maintained and used in-house. As most in-house non-shared code (in any language), it is impenetrable unless you take apprenticeship. The masters are typically old and FORTRAN is their language and it is the only choice for the apprentices. Once the apprentices graduate and become masters themselves, they further developed their own in-house code and it is inevitably in FORTRAN too. As any over-developed code, it is too expensive to migrate even when the new master recognize the shortcoming. The bottom line, FORTRAN is not bad once you are familiar with (and invested in) it, so FORTRAN persists over another generation of apprentices ... However, there is slight change. The new generation of masters often do know other languages, so they sometime tolerate their new apprentices to use other language and still able to teach them. So at this point, by far, not all physicists use FORTRAN. FORTRAN will die out, just takes time. One of the sticking point is the library BLAS/LAPACK. It is in FORTRAN. Or more precisely, its interface is in FORTRAN. I don't foresee this will change for a long time. So FORTRAN will be like COBOL, it will persist even when no-one really use it anymore.
- goerz 10y ago
  I think that's only party true. Physicists would probably not be exposed to Fortran if it wasn't for "apprenticeship". But the same would be true for any other very domain-specific language (let's say Mathematica). However, that doesn't change the fact that Fortran (in its modern syntax) is a great language for numerics. Its abstractions are extremely well-suited for any computation focusing on multidimensional arrays. It is certainly a more expressive language for numerics than C/C++ (and it's not as easy to shoot yourself in the foot in Fortran). There's not that many other languages that can compete for high performance applications. Julia looks like it can do some interesting things. Python is great as a glue language (but not for number crunching, and of course it's slow). I would still (and regularly do) choose Fortran for new projects. It's not going away anytime soon.
  - hzhou321 10y ago
    Let's see how I may clarify the argument. First, if one is familiar with a language or invested in a language, he will be biased to choose that language and it makes sense for him. Before you would argue, I admit I can't prove that you are biased, but nor could you prove you are not biased. So let's agree that some anecdotes like your case is not a strong argument. So let's look at it in another angle. If physicist/people choose FORTRAN not merely due to apprenticeship, it necessarily means that there will be people choose FORTRAN even when his master do not introduce/require him to use FORTRAN. In another word, we need examples of people who choose FORTRAN despite of non-familiarity to FORTRAN. There are plenty of such cases for, e.g. rust. For me at least, I know none such. How about you? For example, how successful have you been influence other people (other than your student) to use FORTRAN? On the other hand, I do know people who choose other language despite of the familiarity of FORTRAN.
orionblastar 10y ago
Interesting as I learned WATFIV on an IBM 370 with JCL/JECL under DOS/VSE. There is an Openwatcom project that does C and Fortran but I think it is Fortran 77. I had Fortran and COBOL on my resume but most jobs I took used Visual Basic.
tomw2005 10y ago
In our company we still us FORTH because the timing of each command is well known.

205 points by urs 10y ago

1. A program from 30 years ago will compile and run. 2. As a research student your first program is likely to be a F77 program written by your professor or an older colleague. 3. A library from 30 years ago can be easily wrapped into a modern program, compiled and run. 4. Arrays are really the most important thing for this sort of programming and since F90 array level operations have been baked into the language. 5. It is fairly trivial to write fast Fortran. 6. Fortran is much easier to use for numerical stuff than c++

ChuckMcM 10y ago

"Early Fortran (designated in allcaps as FORTRAN)" that would be because it is an acronym "FORmula TRANslator". Fortran continues to do that well. And as the article mentions scipy doesn't run as fast. The logical successor to Fortran was APL (Arithmetic Programming Language) but its notation really killed it. The properties that keep Fortran rolling (easy to start using, effective in translating formulas into computation) persist.

thescribe 10y ago
I'm ignorant about FORTRAN, have there been attempts to modernize it? Maybe something like coffeescript/typescript?
- h4nkoslo 10y ago
  The latest major Fortran version, circa 2003, is at least as modern as something like C++.
  - bmh100 10y ago
    I would also like to add that there have been revisions in 2008 and 2015 [1]. [1]: http://fortranwiki.org/fortran/show/Fortran+2015 http://fortranwiki.org/fortran/show/Fortran+2015
- an_d_rew 10y ago
  Fortran 2000 and beyond IS a very modern language.
- ms013 10y ago
  You didn't read the article apparently. Fortran (which officially dropped all caps in the standard in 1990) has had new versions every couple years, up to 2013. Each revision of the language brings modern features into it, and old features go through a process of deprecation and then obsolescence. Most people seem to be unaware that it is an evolving language that has changed significantly since the standard most people are familiar with from 1977. I am a bit biased though: I work on a Fortran compiler, so I've had reason to stay on top of the standards as they come out.
  - thescribe 10y ago
    I misread that everything was backwards compatible, my bad.
- mhd 10y ago
  In the 70s, when Fortran 66 still ruled the night, the usual suspects at Bell Labs wrote Ratfor, which was pretty much what Coffeescript did to Javascript, bending the syntax towards C. When you compare the current Fortran standards to its '66 version, you'll see how much progress it made. And I hope that you can actually use it these days. Round the turn of the millennium, it was still quite common for people to use Fortran 77 because that's all that was supported or fit in the general codebase.
nikofeyn 10y ago
APL is named after Kenneth Iverson's book "A Programming Language".

hcrisp 10y ago

FORTRAN may be faster but one graph shows Python recently overtaking it in mentions of Astronomy papers [0]. [0] https://mobile.twitter.com/astrofrog/status/787007261877166080 https://mobile.twitter.com/astrofrog/status/7870072618771660...

arcanus 10y ago
A great deal of that is for post-processing, however. Very little python used in the compute heavy pieces of scientific computation.
- maus42 10y ago
  I know a person who works in atmospheric physics group. All the heavy physics simulation and modeling happens in Fortran, and then they do the "lighter" analysis, summary statistics, plots, visualizations, etc with a Python-based stack.

santaclaus 10y ago

What ever happened to the effort to bring Fortran to LLVM (from Los Alamos I think)?

lightsighter 10y ago
Still in development (paid for by LANL, done by PGI): https://developer.arm.com/-/media/developer/developers/hpc/files/ARM-HPC-UG-SC16-PGI.pdf?la=en https://developer.arm.com/-/media/developer/developers/hpc/f...

PaulHoule 10y ago

Even if you are using python, R or java you are still best off linking to matrix subroutines in fortran if you want to solve or diagonalize, get eigenvalues and such. This is not just about raw performance but also correctness, ecology of roundoff errors, etc.

ricree 10y ago
For Python, at least, the most popular numeric computation library (NumPy) uses a fair bit of Fortran under the hood. I'm not certain whether the matrix operations do, but it certainly wouldn't surprise me.
- nerdponx 10y ago
  Doesn't NumPy just use BLAS and LAPACK for matrix operations?
  - ThatGeoGuy 10y ago
    The vast majority of BLAS and LAPACK are written in Fortran (at least, the ones provided by netlib.org). Github also reports that OpenBLAS is around 50% Fortran, so there's quite a bit there too [1]. Usually when you call BLAS functions from C you're really calling a cBLAS wrapper to some Fortran function. This is generally why you see -lgfortran -lf77blas when you compile programs that require numerical tools. [1] https://github.com/xianyi/OpenBLAS https://github.com/xianyi/OpenBLAS
    - simonster 10y ago
      At least in OpenBLAS, most (all?) of the BLAS routines are C functions that call kernels written in assembly, but many of the LAPACK routines are the Netlib reference Fortran versions.
qznc 10y ago
Yet, I root for D and its GLAS library [0]. It is a young project, but it beats the usual suspects for single-threaded matrix-multiplication. Stuff like "solve or diagonalize, get eigenvalues and such" is not written yet. It is very promising for a one-man project, though. We'll see in 10 years, I guess. Fortran certainly has a mythical reputation for performance, but it should be challenged every once in a while. [0] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

srean 10y ago

Guy Steele and his group had a really interesting thing going with the language Fortress (name is a nod to Fortran of course, but fortified). It was meant for high productivity as well as high speed (petaflops range). It got shelved after Oracle bought Sun. It was one of the three languages seeded by DARPA funding for high productivity computing https://java.net/projects/projectfortress/pages/Home https://java.net/projects/projectfortress/pages/Home https://blogs.oracle.com/projectfortress/entry/fortress_wrapping_up https://blogs.oracle.com/projectfortress/entry/fortress_wrap...

nickpsecurity 10y ago
Look up ParaSail. It's still in development that Im aware of.
pjmlp 10y ago
> It got shelved after Oracle bought Sun. Actually the actual real history is little more complex than that. JuliaCon 2016 (Keynote) | Fortress Features and Lessons Learned | Guy Steele https://www.youtube.com/watch?v=EZD3Scuv02g https://www.youtube.com/watch?v=EZD3Scuv02g It would be good if people on HN would separate a bit the Oracle hate with the facts.
- srean 10y ago
  The causation was certainly not intentionally implied in my comment. I was stating temporal ordering fact. Hold on to your oracle defense response :)

spapas82 10y ago

One interesting fact that supports the point of the article is that Matlab is actually using the Fortran code for its implementation of special functions https://www.mathworks.com/matlabcentral/fileexchange/6218-computation-of-special-functions https://www.mathworks.com/matlabcentral/fileexchange/6218-co.... The amount of existing scientific code in Fortran is huge and there's a chicken and egg situation (new code uses/extends old code so new code will also be in Fortran) that will lead to further increasing it!

spott 10y ago
Matlab also uses MKL (written in fortran, with a heavy dose of assembler) for its blas routines I believe.

jstewartmobile 10y ago

It's funny that someone has to write an article to defend modern FORTRAN to people who write in JavaScript, which is the best proof we programmers have of entropy.

taejavu 10y ago
It's funny that in every discussion of programming languages that have nothing to do with Javascript, there's always some smug bastard bashing it.
- jstewartmobile 10y ago
  Because it's really that bad, and we all have to use it because somehow, Brendan Eich's cocktail-napkin language became the VM of the web.
  - taejavu 10y ago
    Yes but if you go into a discussion of Star Trek movies complaining loudly about how bad you think the new Star Wars is, you're completely irrelevant at best.
  - andrepd 10y ago
    Yes, and what does that have to do with this article? If you come to a discussion about thing x to complain about thing y, no matter how valid your complaint you are out of order. To quote The Dude: "You're not wrong, you're just an asshole."
    - jstewartmobile 10y ago
      They're both languages. Just pointing out the irony of this guy taking the time to explain why Castro isn't such a bad guy to a world of Stalinists.
    - Annatar 10y ago
      Yes, and what does that have to do with this article? Excellent question, glad you asked! Just what do you think all the people who are asking why Fortran is still in use are using? My money is on the bet that they're not using Fortran. I've worked in the finite element analysis / high performance computing fields for quite a few years and I've never heard anyone who used Fortran complain that they were, or had to use it. Could it be that it's because people like that they get high performance from a language out of the box?

supergarfield 10y ago

> Interestingly, C/C++ beats Fortran on all but two of the benchmarks, although they are fairly close on most. Unless I missed something, this directly contradicts the quotes benchmark source[1], where C beat Fortran on all tests except one (where they were tied), and usually by a wide margin. Plus I believe gcc usually produces slower code than Intel's compilers (at least for C), so it's not clear that C-gcc and Fortran-Intel is a fair comparison. But beyond that, I'm always confused as to why there is a significant difference. I would expect two compiled languages with reasonable compilers to perform almost exactly the same when they're doing nothing but arithmetic operations, since those are almost entirely determined by the CPU, not the cleverness or speed of the standard library algorithms. Can anyone enlighten me? [1] https://benchmarksgame.alioth.debian.org/u64q/fortran.html https://benchmarksgame.alioth.debian.org/u64q/fortran.html

santaclaus 10y ago
> I would expect two compiled languages with reasonable compilers to perform almost exactly the same when they're doing nothing but arithmetic operations Auto-vectorization? These implementations vary wildly between GCC and Intel.
jstewartmobile 10y ago
Lies, damn lies, and benchmarks. I know as a long-time C programmer, there are small changes I can make to source that will result in big-time performance gains. Could hinge on how tight their FORTRAN code is vs their C code... Could also depend on how much love their respective machine code translations have been getting.
- dfgasfjhjhsdojj 10y ago
  Fortran hasn't been all caps for nearly 30 years now... It is very easy for a physical scientist to write Fortran that performs well - the syntax looks very similar to the maths that is being modeled. It is a lot harder for a scientist to write tight C code.
  - 10y ago

pif 10y ago

> If a function that takes a ‘real’ is fed a ‘const real’, it will return an error. It is easy to imagine how this can lead to problems with interoperability between codes. What's he talking about? This is wrong!

syphilis2 10y ago

I've been looking for a Matlab alternative and been disappointed with either the performance or the syntax of Octave, Python, and Julia. I'd known Fortran had modern features and updates every few years, but never tried to pick it up since the excitement seems to be elsewhere. This article is convincing that Fortran is worth trying out.

bmh100 10y ago
If you want to get down into the nuts and bolts of numerical computation, with convenient concurrency, you should definitely look into Fortran + OpenMP.
Xcelerate 10y ago
What don't you like about Julia's syntax? Is it more than the 1-based indexing and "end" statements?
- goatlover 10y ago
  Agreed, Julia syntax is very clean. Also, you can make it look more math-like with it's support for unicode variable and function names.

Animats 10y ago

Fortran is still better at multidimensional arrays. Other than Matlab, few other languages do multidimensional arrays at all. C-derived languages use arrays of arrays, and use templates, macros, or objects for multidimensional arrays. Fortran optimizers have lots of multidimensional array-oriented optimizations which other compilers usually lack. I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but slower representations so you could take arbitrary N-dimensional slices from a multidimensional array.

ryescienceguy 10y ago
> I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but slower representations so you could take arbitrary N-dimensional slices from a multidimensional array. This is the most frustrating aspect of Rust, to me, as a developer of scientific software. Rust has great potential to challenge Fortran in this domain, but numerics is mostly an afterthought in Rust.
- throwaway7645 10y ago
  Agreed. I want to write numeric software, but don't want to use Fortran or C++. Rust looked great, but I couldn't find anything in this domain.
  - goatlover 10y ago
    Julia has strong numerical and multi-dimensional array support, but it's JIT compiled. However, once a function is JITted, it has comparable performance to Go & Rust.
    - divbit 10y ago
      Seconded for Julia. I have been using it for math prototyping and it's recently replaced my old favorites like matlab / python / lua.

troymc 10y ago

When I was doing my graduate studies in astrodynamics (spacecraft trajectory design) at Purdue University circa 2003, we worked closely with the Jet Propulsion Lab (JPL) and got to use a lot of their excellent astrodynamics code (used for missions like Galileo and Cassini). It was all Fortran. I heard that there was an effort at JPL to convert over to using Python. I'm not sure how that went. Maybe they were just writing Python bindings for their Fortran code? I know that much of SciPy consists of Python bindings for Fortran and C code [1]. The software I used to do "nonlinear programming" (i.e. parameter optimization), called NPOPT, was also written in Fortran. [1] https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fast-if-it-is-written-in-an-interpreted-language-like-python https://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fas...

mturmon 10y ago
The Python replacement succeeded - I slightly know the people involved, who got an award for the work. But I don't use the library so I don't know if the wrapper approach was used. That would be perfectly legit IMHO.

bmh100 10y ago

Fortran is an excellent choice for numerical computation. Its non-aliasing assumption allows for compiler optimizations that dramatically speed up computations. It is even easy to get started with concurrent code through OpenMP. When I need to run a simulation or a discontinuous optimization algorithm, I turn to Fortran first. Here are some resources I have collected over the years. "Introduction to Modern Fortran" (Fortran 2003): http://people.ds.cam.ac.uk/nmm1/Fortran/index.html http://people.ds.cam.ac.uk/nmm1/Fortran/index.html Fortran Wiki: http://fortranwiki.org/fortran/show/HomePage http://fortranwiki.org/fortran/show/HomePage List of Fortran tutorials: http://www.fortran.com/the-fortran-company-homepage/fortran-tutorials/ http://www.fortran.com/the-fortran-company-homepage/fortran-... Fortran vs. C: http://www-cs-students.stanford.edu/~blynn/c/fortran.html http://www-cs-students.stanford.edu/~blynn/c/fortran.html Fortran's influence on C's "restrict" keyword: http://www.drdobbs.com/the-new-c-it-all-began-with-fortran/184401313 http://www.drdobbs.com/the-new-c-it-all-began-with-fortran/1...

castratikron 10y ago
To be fair, there are GCC built-ins that allow you to tell the compiler that arrays are nonaliasing, but you're right in that it's more difficult in general to get a compiler to spit out fast numeric code with C than it is with Fortran.
- bmh100 10y ago
  I feel like it's a "right tool for the job" situation. Fortran was literally built for the purpose of numerical computation. Multi-dimensional arrays, non-aliasing arrays and pointers, multi-dimensional array intrinsics, intrinsic array binary operators... all come with Fortran right out of the box. Of course, C/C++ can do all of these things, but all of the proposed methods, at least that I have seen, feel like they are trying to hammer a screw.
pmiller2 10y ago
Glad this was posted. First thing I did on loading the comment section was ^F "alias". Fortran is still used for numerics because it makes writing fast numerical code easy. C simply wasn't designed for it, just as Fortran wasn't designed for low level system/OS programming.

davidf18 10y ago

It seems like a number of R packages use Fortran. I'm on Mac and it needs to Fortran compiler to be installed so that at least some of the R packages can be compiled when doing updates.

bachmeier 10y ago
R (the language, originally S) was created to be a "glue language" for compiled code, most of which was written in FORTRAN.

pducks32 10y ago

As a physicist please have faith in us. We don't all use Fortran. I use Ruby as much as possible and it's fun because it forces me to write libraries that mimic ones that are found in other languages. So I end up learning a lot.

yxhuvud 10y ago
I can recommend looking at Crystal if you have some time over. Very Ruby-like syntax, but compiles down to quite efficient native code.
bmh100 10y ago
How are you using Ruby for physics?

radioactivist 10y ago

The author is I think being a bit unfair to C++ when it comes to matrix/array handling. Their example of things that would be difficult to do in C/C++: A = B A = 3.24 * B C = A * B B = exp(A) norm = sqrt(sum(A * * 2)) Quoting: "Similar C/C++ code simply does not exist ... Having to use libraries instead of intrinsic functions means the resulting code is never as neat, as transferable, or as easy to learn." While this statement is true, I think strongly undersells how well these kinds of libraries can be "baked" into C++ through operator overloading, templating, etc. See for example, the Eigen library [http://eigen.tuxfamily.org/ http://eigen.tuxfamily.org/].

deleted 10y ago
[deleted]
m_mueller 10y ago
here's the problem: These kind of libraries will never come close touching Fortran's built-in features, simply because the compiler can't automatically optimise for knowledge about the code that only the library has. Even arrays not knowing their size is still an issue, let alone array based ops like shown in the article. Fortran is not the fastest language around the block, but if you don't want to go into non-portable machine-based hand-tuned optimisations (e.g. loop unrolling) it's hard to beat. Basically, if you optimise for both runtime and programmer time for HPC applications I'd argue that Fortran is top of the crop.
- radioactivist 10y ago
  Well, in the case of Eigen it's an entirely header based library, so the compiler can optimize some things. Not to mention the template based meta-programming strategies [1] Eigen itself uses to simplify and optimize during compilation (including vectorization and loop unrolling). The fact that this kind of infrastructure can be built up in a library in C++, i.e. it doesn't have to be baked into the compiler, is a huge plus I think relative to Fortran. [1] https://eigen.tuxfamily.org/dox/TopicInsideEigenExample.html https://eigen.tuxfamily.org/dox/TopicInsideEigenExample.html
- whyever 10y ago

spullara 10y ago

When I was in undergrad I did some computer simulation work for my professor. He programmed in FORTRAN while I had been trained in C/C++. I did my simulations in C/C++ and I also wrote some libraries for his FORTRAN code so he could have more dynamic configuration files. At the time I thought that FORTRAN was an anachronism and was surprised that it was still being used in physics. This was 1992.

Asooka 10y ago

I have one issue with the article. The way to dynamically allocate a multidimensional array in C is the following: size_t m, n; ... set m and n ... int (*a)[m][n]; a = (int(*)[m][n])malloc(sizeof(*a)); Edit: and you MUST NOT REUSE OR OTHERWISE CHANGE m and n FOR THE ENTIRE LIFETIME of the array, because bad things will happen. And you access it via (*a)[x][y] And you free it with free(a); And if you want to pass it to a function: void do_with_array(void* raw_array, size_t m, size_t n) { int (*array)[m][n] = (int(*)[m][n])raw_array; ... do whatever ... } do_with_array(a); And I'd rather do it in Fortran, but if you ever need to do it properly in C (i.e. without using array of pointers) - now you know.

SFJulie 10y ago
Technically you are right. Practically you are right, but the article is more right than you. I got into some fights with quite a few elite teachers/coders teaching the way of doing 2D arrays exactly as described, and they wouldn't agree the method you describe is less error prone ... because: it is tradition. (And as every person doing research know tradition is not supposed to change and that what science values). It seems absurd, but so many things are absurd these days I am not even surprised.
- Asooka 10y ago
  Oh, the method I describe is more error prone than array of arrays, because if you ever modify the two variables you used to specify the array size, the compiler will just use the new values for array dimensions. If I had to do array of arrays though, I'd at least do something like template<typename T> T** make_2d_array(size_t m, size_t n) { // TODO: add padding for alignment, // but you're unlikely to need something aligned // on a larger extent than sizeof(void*) void *memory = malloc(m * sizeof(void*) + m * n * sizeof(T)); T** array = (T**)memory; T* data = (T*)((char*)memory + m * sizeof(void*)); for (size_t i = 0; i < m; i++) { array[i] = data + i * n; } return array; } And you can then delete the entire array with a single free().
acqq 10y ago
If I understand, your solution, as it is, would still be wrong to be passed to the Fortran code as in Fortran the column index is faster changing. And if you would blindly translate some FORTRAN code to C with the above arrays, even if you'd get the same results the C one would be slower because of that, as the FORTRAN code could have been written with the knowledge of which index arrangement is faster.

smegel 10y ago

> Note that Python, which is the darling of computer scientists Actually physical scientists love Python as much as they love Fortran. It a lot of cases, it is the only two languages they know.

SFJulie 10y ago

Just in case you want to use fortran code in python here is the scipy HOWTO Still up to date. https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-as-glue.html https://docs.scipy.org/doc/numpy-1.10.0/user/c-info.python-a...

theden 10y ago

My reason for using fortran (when I was studying physics) was that when going through the university library looking for a computational physics textbook, I couldn't find one that wasn't in fortran—actually I found one (computational physics, Giordano & Nakanishi) but it wasn't enough to get by. Fortunately I already knew fortran, because all the legacy textbooks+journals were written in the language.

jheriko 10y ago

some of the information here is a bit wrong. the idea that const is weaker than parameter is true, but not for the reasons given. any function taking a float, int etc. in C++ can also take a const float or const int. its also unfair to suggest that C/C++ is as fault with not allowing a = b * c with array types. this is a failing of the standard library and easily fixed... operator overloading lets you create exactly this functionality, and std::valarray already does this for a lot of what you get in Fortran...

pklausler 10y ago
Good luck getting a high performance implementation of A=B+C without memory allocation out of a library.
- jheriko 10y ago
  rolling your own is pretty easy, it is a shame that the C++ standard library is a dire wasteland of bad implementations. you are right that valarray will do heap allocations and making it work on the stack is a real ballache.
- whyever 10y ago
  This is really not hard using expression templates.

hzhou321 10y ago

It is simply due to apprenticeship. Physicists do research, and their code is research code. Like most other research, the research code is maintained and used in-house. As most in-house non-shared code (in any language), it is impenetrable unless you take apprenticeship. The masters are typically old and FORTRAN is their language and it is the only choice for the apprentices. Once the apprentices graduate and become masters themselves, they further developed their own in-house code and it is inevitably in FORTRAN too. As any over-developed code, it is too expensive to migrate even when the new master recognize the shortcoming. The bottom line, FORTRAN is not bad once you are familiar with (and invested in) it, so FORTRAN persists over another generation of apprentices ... However, there is slight change. The new generation of masters often do know other languages, so they sometime tolerate their new apprentices to use other language and still able to teach them. So at this point, by far, not all physicists use FORTRAN. FORTRAN will die out, just takes time. One of the sticking point is the library BLAS/LAPACK. It is in FORTRAN. Or more precisely, its interface is in FORTRAN. I don't foresee this will change for a long time. So FORTRAN will be like COBOL, it will persist even when no-one really use it anymore.

goerz 10y ago
I think that's only party true. Physicists would probably not be exposed to Fortran if it wasn't for "apprenticeship". But the same would be true for any other very domain-specific language (let's say Mathematica). However, that doesn't change the fact that Fortran (in its modern syntax) is a great language for numerics. Its abstractions are extremely well-suited for any computation focusing on multidimensional arrays. It is certainly a more expressive language for numerics than C/C++ (and it's not as easy to shoot yourself in the foot in Fortran). There's not that many other languages that can compete for high performance applications. Julia looks like it can do some interesting things. Python is great as a glue language (but not for number crunching, and of course it's slow). I would still (and regularly do) choose Fortran for new projects. It's not going away anytime soon.
- hzhou321 10y ago
  Let's see how I may clarify the argument. First, if one is familiar with a language or invested in a language, he will be biased to choose that language and it makes sense for him. Before you would argue, I admit I can't prove that you are biased, but nor could you prove you are not biased. So let's agree that some anecdotes like your case is not a strong argument. So let's look at it in another angle. If physicist/people choose FORTRAN not merely due to apprenticeship, it necessarily means that there will be people choose FORTRAN even when his master do not introduce/require him to use FORTRAN. In another word, we need examples of people who choose FORTRAN despite of non-familiarity to FORTRAN. There are plenty of such cases for, e.g. rust. For me at least, I know none such. How about you? For example, how successful have you been influence other people (other than your student) to use FORTRAN? On the other hand, I do know people who choose other language despite of the familiarity of FORTRAN.

orionblastar 10y ago

Interesting as I learned WATFIV on an IBM 370 with JCL/JECL under DOS/VSE. There is an Openwatcom project that does C and Fortran but I think it is Fortran 77. I had Fortran and COBOL on my resume but most jobs I took used Visual Basic.

tomw2005 10y ago

In our company we still us FORTH because the timing of each command is well known.