A large research project in the physical sciences usually involves experimenters, theorists, and people carrying out calculations with computers. There are computers and terminals everywhere. Some of the people hunched over these screens are writing papers, some are analyzing data, and some are working on simulations. These simulations are also quite often on the cutting edge, pushing the world’s fastest supercomputers, with their thousands of networked processors, to the limit. But almost universally, the language in which these simulation codes are written is Fortran, a relic from the 1950s.
Ars looks at three possible replacements for Fortran.
So, I’ve been coming to this site for a very long time and never commented. Signed up just because of this article.
What I’d like to know is what universities were sampled when Ars wrote this article?
I go my Bachelor’s degree in Mechanical Engineering in 2006 and a Master’s in Industrial Engineering in 2011, yet, I have only every seen 1 piece of code written in Fortran and it was used as an example of how old engineers did things. At least the schools I’ve attended use MATLAB for writing programs and it’s companion Simulink for simulation.
Ars makes this blanket statement “Take a tour through the research laboratories at any university physics department or national lab”, but the only examples they give are for “national labs” like NASA, National Center for Atmospheric Research, etc. I have never worked at NASA, having studied at the University of Central Florida in Orlando, FL, I visited some of companies doing work for NASA and none of them were using Fortran.
This is my experience, and it conflicts with Ars’ article, so I’d like to know where this data is coming from.
They’re talking about HPC. Back when I was working at Quadrics (around 6 years ago now) Fortran was the top tier language, followed by C, and the Python was just beginning to bring up the rear.
Fortran has stuck around in HPC for decades now, and even C & Python haven’t unseated it, so I wont hold my breath on Clojure making any serious inroads this side of 2030.
I think their idea about Clojure is more to do with it being used for big data, which isn’t quite the same as HPC.
In terms of performance most commercial Common Lisp compilers are way better than current Clojure implementations.
When I was at CERN it was all about Fortran and C++.
Julia might have more possibilities pushing Python and R away than Fortran.
Why Fortran though? Using Fortran for HPC feels, to me, like building high-performance cars with steam engines.
I’m could be totally wrong of course but that’s how it feels.
Why? Because the language is old? It has progressed a lot since the Fortran77, the last version of the language most people were exposed to.
It is a fully modern language, but since it doesn’t have the same kind of optimization problems a language like C might have (pointers and aliasing make lots of things very tricky) to optimize it is an easier language to optimize and parallelize.
I wouldn’t want to write a word processor written in Fortran (though I worked on one that was), but if you are doing heavy compute work Fortran is a good tool for the job.
Edited 2014-05-09 15:27 UTC
Fortran is still very popular among the computational Physics/Astrophysics and Chemistry crowds for a few reasons:
1. The language is designed for their needs, literally.
2. It’s also relatively simple, and it’s very easy to be proficient in it.
3. There is a huge inertia since the language has been around for 5 decades, so there is tons of code and libraries. People don’t want to reinvent the wheel if they don’t have to.
4. Optimizing Fortran compilers are very good by this point, and still produce better performing code than comparable C++ compilers in some cases (for the type of codes involved). This makes a huge difference in HPC.
5. Engineering is not a science. So the mindset of the professionals in either field tend to be different. E.g. a delivery van driver has a different relationship with the vehicle (as a tool to do his job) than the mechanical engineer that designed it (as the end goal of his job).
If you look at the syllabus for any major (or competitive) Physics, Astrophysics, or Chemistry programs there is a high probability that Fotran literacy is still a requirement.
I personally think the Ars article was off by considering either Clojure or Haskell; both languages present significant steep learning curves to non CS types. Julia is more a propos. Probably they should have explored C/C++. But I assume that would have been far less sexy.
Having no experience with HPC, I have no arguments against your points. But that lasted up until I got to this one,
Your argument here is just completely flawed. Engineering is science, and more specifically, it is the applied version of a science, be it physics, mathematics, Chen chemistry or any of the other many sciences.
On top of that glaringly flawed statement, I’m not entirely sure where you were trying to get with your van driver analogy. Are you trying to argue that science is simply a tool for an engineer, and the end goal of a physicist, chemist or mathematician? If that is it, you have obviously never been involved in an university that did serious research. My experience is actually that research topics usually overlap between these disciplines.
Are you speaking from actual experience or are you guessing? On top of my real job, I also teach college classes as an adjunct professor and programming is one of the required courses for graduation. I can assure you it isn’t Fortran.
Again, my experience is in engineering, not the HPC. However, the article never once specified HPC, it said “physics research labs”, which are not the same thing.
I agree with you on this point. I didn’t even know what Clojure was until this article. I’ve tried Haskell, but found it too complicated.
My opinion is that these fields require very sequentially thinking, only that they must be done in very large quantities of days. A good example of this is the programming behind a finite element analysis program. The operations are simple and must be fine in sequence, the problem being that you’re dealing with a 1 million by 1 million matrix.
EDIT: Typing this on my tablet makes for some interesting autocorrects.
Edited 2014-05-09 00:59 UTC
I meant what I said, engineering is not a science.
http://spectrum.ieee.org/at-work/tech-careers/engineering-is-not-sc…
Interestingly enough, significant portions of Mathematics are also not a science, but that is neither here nor there.
Sigh. What I meant to imply is that from the scientist’s point of view, computing is yet another tool for them to conduct/enable their research (which is their end goal). That is a different context from the engineer designing/manufacturing said tools, because the tools themselves are the results for him/her.
Thus why a lot of physicists et al use FORTRAN; because it works and produces the result they require so they can move on with their lives, and why CS/CE types obsess over why some scientist would use FORTRAN instead of other programming languages.
I’m talking both from actual experience and knowledge in the matter, plus I have plenty of colleagues with advanced degrees in science and I’m aware of the realities of their research at the university, national lab, NASA, and industry levels. BTW, I have actually worked at NASA (JPL) and I had a few internships involving research in physics, so I have seen and had to optimize my share of FORTRAN code (ugh).
You can perform a simple google query with the terms “University” and “FOTRAN” if you require further examples.
Pro tip: Perhaps you should be more careful using so freely your personal experience in the matter, esp when it’s not very authoritative, when being argumentative. Even more so if you’re going to question other people’s credentials in the field from just a single post.
Edited 2014-05-09 03:32 UTC
From my experience, Fortran still has a very large presence on civil and mechanical engineering. Most of the underlying code to handle differential equations on boundary problems and truss analysis that I have seen are coded in Fortran. There is a ton of old and tested code to handle eigenvalue/eigenvector solutions of many kinds, matrix factorization, polynomial root finding and so on and so forth.
The main difference I have seen is that the old crude command line interface was changed to use Python or C++/Qt.
Some of the vantages of Fortran include:
– it has intrinsic complex type;
– it has guarantees about numerical precision;
– matrix handling is best than what we have on C/C++ from a compiler point of view (it is easier to be optimized);
– it is relatively easier to grasp and faster to deploy (if we ignore the input/interaction aspect);
– did I say that it has an exponential operator? (OK, this last one is here just because I like it).
Of course, it has its drawbacks but, overall, it is a very good language that has handled very well the aging.
About a replacement, again from my experience, most of the engineers and physicists I worked with were very practical guys that would gladly use something tested on battlefield whenever possible.
Matlab (and Octave) is intensively used on most places I went and, sometimes, interfacing it with c/fortran libraries is a must. And here is where Julia as replacement falls short, the development environment is not ready yet. It can not be compared with what we have on Matlab and IPython. And the claims that Julia is a lot faster, well, of course if you code a particular matrix solving technique on a source .py or .m file that is going to be true but that is not what happens commonly (again, where I worked). Critical code were always written on c or Fortran so that the difference on execution speed is insignificant on real cases at best or were not a concern from start, practical use being more important on some cases.
Edited 2014-05-09 02:21 UTC
Interestingly enough, I have been testing Julia using iPhython as a front end.
http://nbviewer.ipython.org/url/jdj.mit.edu/~stevenj/IJulia%20P…
Your comment on the state of Julia is totally on point, BTW.
From what I have read it seems to me that Julia is Common Lisp with a C-like syntax.
That title is already owned by Dylan.
Dylan died a long time ago and has a weird syntax.
It’s still around in zombified form:
https://opendylan.org/
What is wrong with it? Why replace it?
Hi,
A computer only does about 25 simple things (copy, add, subtract, …, compare, branch).
It’s a language designer’s job to make it seem complicated by combining multiple simple things. Examples include the “+=” operator in C/C++ (which combines copy/assignment and addition), a typical loop (that combines comparisons and branches), and templates in C++ (that combine higher level things with Cthulhu).
Basically, language designers don’t like Fortran because they don’t think it’s complicated enough. They’d much rather see something like Haskell. Their theory is, nobody ever complains that Haskell isn’t complicated enough, therefore it must be good.
– Brendan
You can further abstract it.
A computer
* loads a data item
* performs an operation on data
– arithmetic/logic operation
– jump operation
* stores a data item
And as I stated before:
Lisp is the proof that code and data are isomorph.
As a result a data item might be an instruction.
Greetings,
pica
Edited 2014-05-09 11:25 UTC
both FORTRAN and COBOL. PL/1 was intended to be the (only) one programming language needed.
And now, both FORTRAN and COBOL are still used. PL/1 is unknown to most people.
And since FORTRAN 90 (aka 8X with the roman X = 10) FORTRAN is not the old FORTRAN anymore. FORTRAN 90 and newer offer structured condition and loop commands, offer a module system with IN and OUT restrictions, offer …. The new FORTRAN is more like ADA than like the old FORTRAN (I). Nevertheless the new FORTRAN is as fast as the old.
Greetings,
pica
EDIT typos
Edited 2014-05-09 05:58 UTC
Fortran has had structured loop and condition handling since Fortran 77. And despite the bad example in the article (the do… end do don’t require labels) have been there for a LONG time now.
The thing Fortan has lacked for quite some time was data structures… and recursion.
And both of those features are available in the current fortran.
Yes, that is true. But I have not denied this, or have I?
pica
As one of the few(!) who actually enjoys C++, I can tell you that there has been a real spike in demand for C++ in HPC/scientific computing projects in recent years. I’ve heard of people doing Haskell and Clojure for financial computing, but not scientific computing, and I’ve never even heard of Julia. Either I’m out of the loop (entirely possible), or the authors of this article aren’t talking to the same people I’m talking to.
Edited 2014-05-09 06:51 UTC
Yes, LANL, JPL, ARC, ZAM and many other institutes used C++ for HPC numerics even in ’97. But FORTRAN has not been replced in the meantime.
pica
I worked in the HPC industry for twelve years, and we used Fortran exclusively (my old company still do) for exactly two reasons:
1) The optimizers in Fortran compilers is numerical analysis centric, and can turn a ton of code into their SIMD’y equivalent.
2) An expert can look at a piece of Fortran code and pretty much understand how it will map to the HPC’s cpu and numa structure. That’s extremely important when you need to squeeze out every nanosecond possible in a tight loop.
Haskell as an alternative? No way, it’s lazy evaluation approach makes it almost impossible to reason about performance.
Edited 2014-05-09 10:15 UTC
I’ve worked as a tech support at one of our large national labs. FORTRAN is still in use because non-computer people find it relatively easy to write and it expresses their problems clearly and succinctly. A number of scientists, engineers, etc. still sometimes use FORTRAN, believe it or not. Also, there are still many scientific programs written in FORTRAN, and this community has problems to solve. They don’t spend their time on converting old programs that work to newer programming languages. Many ancient FORTRAN programs are still in service.
The article mentions C++. I can tell you NO scientists use it. Weird syntax, too difficult. Scientists may contract for a system to be written for them in C++ but they NEVER write it themselves. C fell to the same fate. We in CS and IT like these languages, but few do outside our profession.
That’s really quite an odd thing to say. I’ve seen tons of scientists using C++ at CERN and Fermilab. I was one of them.
You were not.
Damn. I must have imagined that whole period of my life during my twenties and thirties where, having finished my Ph.D. at Cambridge, I then went on to work at (among others) CERN and Fermilab. I’ve also clearly imagined all of the C++ code I didn’t write that made its way into such diverse frameworks as ROOT and Cactus.
But thankfully there’s a man on the internet to remind me that it didn’t happen. Thanks for that, anonymous man on the internet!
I don’t know… if there’s something scientists can handle, it’s weird syntax. As for too difficult, that’s only if you want to write a templated library, or if your code really depends on the semantics of copying vs moving and l-value vs r-value references.