Slashdot Mirror
A C++ Library That Brings Legacy Fortran Codes To Supercomputers
gentryx writes "In scientific computing a huge pile of code is still written in Fortran. One reason for this is that codes often evolve over the course of decades and rewriting them from scratch is both risky and costly. While OpenMP and OpenACC are readily available for Fortran, only few tools support authors in porting their codes to MPI clusters, let alone supercomputers. A recent blog post details how LibGeoDecomp (Library for Geometric Decompostition codes), albeit written in C++, can be used to port such codes to state-of-the-art HPC systems. Source code modification is required, but mostly limited to restructuring into a new pattern of subroutines."
...like rice, is not countable. At least not since I learned the word.
In old codes, you're already familiar with the existing quirks and bugs, and the base is heavily patched up from years of debugging.
I read TFA and all I got was this lousy cookie
Fortran is by no means outdated. Seriously, check out the new Fortran 2008 standard and its state-of-the-art compilers (e.g. the NAG one).
You'll be blown away by its speed and clean looking code. C++ might have features that fortran lacks (complex template usage seems rather popular), but that doesn't always reduce the development time. At least that my experience.
As long as you're working on scientific projects, fortran is practically unmatched.
have you any idea how much it woudl cost to port it to cludgy C++ (which lacks a lot of things needed for scientific computing) you then have to re-qualify All of your models which is both time and resource intensive.
The IEEE and Los Alamos National Laboratory seem to have a different opinion on this. And even the Oxford dictionary knows the use of codes. But surely those guys can't even spell gigahertz.
Computer simulation made easy -- LibGeoDecomp
I took a look at TFA and followed up by reading the description of LibGeoDecomp:
If your application iteratively updates elements or cells depending only on cells within a fixed neighborhood radius, then LibGeoDecomp may be just the tool you've been looking for to cut down execution times from hours and days to minutes.
Gee, that seems like an extremely limited problem space, and doesn't measure up at all to the title of this Slashdot submission. It might really be a useful tool, but when I clicked to this article I expected to read about something much more general purpose, in terms of 'bringing Legacy Fortran to Supercomputers'.
Correct. We didn't try to come up with a solution for every (Fortran) program in the world. Because that would either take forever or the solution would suck in the end. Instead we tried to build something which is applicable to a certain class of applications which is important to us. So, what's in this class of iterative algorithms which can be limited to neighborhood access only?
It's interesting that almost(!) all computer simulation codes fall in one of the categories above. And supercomputers are chiefly used for simulations.
By the way, regarding the use of the word 'codes': I don't think English is the first language of this developer. Cut some slack.
Thanks :-) You're correct, I'm from Germany. I learned my English in zeh interwebs.
Computer simulation made easy -- LibGeoDecomp
...and has done for years.
We write a scientific code for solving quantum mechanics for solids and use both OpenMP and MPI in hybrid. Typically we run it on a few hundred processors across a cluster. A colleague extended our code to run on 260 000 cores sustaining 1.2 petaflops and won a supercomputer prize for this. All in Fortran -- and this is not unusual.
Fortran gets a lot of bad press, but when you have a set of highly complex equations that you have to codify, it's a good friend. The main reason is that (when well written) it's very easy to read. It also has lot's of libraries, it's damn fast, the numerics are great and the parallelism is all worked out. The bad press is largely due to the earlier versions of Fortran (66 and 77), which were limited and clunky.
In short, the MPI parallelism in Fortran90 is mature and used extensively for scientific codes.
Not at all. It might be a bit more monocultured than, say, C++ but there are still more than enough ways to skin the same cat that you end up with a ton of cat parts and a mass of confusion.
You don't have to rewrite your code entirely, just a little bit.
You only have to restructure the subroutines and change the syntax.
Well, that sounds like rewriting to me. Just because there is a library that might implement the same semantics as FORTRAN's math does not mean that it isn't a rewrite, coming with all the risks for new errors and gotchas that that implies.
I do not fail; I succeed at finding out what does not work.
It is true that there are a lot of legacy Fortran codes in scientific computing, but chances are that they are already parallel, so this tool won't be much of a use for those supporting them. OpenMP and MPI have been in use in Fortran codes for decades. The summary seems to think that legacy Fortran codes need saving and porting. They don't. They are just fine, number crunching faster than you can say DO CONCURRENT.
Having said that, LibGeoDecomp seems quite nice if you find a piece of serial code and you want to make a rough parallel version of it without much hassle. But if you are writing new code, you can parallelize it natively. Nevertheless, I believe that we must focus our resources in developing the current compilers. The Compaq compiler died in the hands of HP and people moved mostly to the intel compiler, since the open-source community was focused in C++ at the time and the gcc was stuck with the obsolete g77. Then g95 came along, that brought us all the cool stuff of Fortran 90/95, while gfortran was being developed. Now gfortran seems decent, but it still has to match the speed of ifort in order to sit at the cool kids' table. Also, we need the features of the latest Fortran standards. I would gladly use a compiler that is feature-complete, even if the executables are relatively slow, because I will be able to switch into the mindset of the Fortran2008 standard and stop doing things the Fortran95-way while coding. They will then have all the time they need to make it more efficient.
Please don't learn FORTRAN, learn Fortran instead. (For the pedantic, all caps is F77. Normal caps is F90 and later.)
You claim to be writing high performance code and you don't understand the difference between Boost multi-array and Fortran arrays? I'm sorry, but if you do any kind of high performance computing, you should at least have a decent understanding of one of the major tools used for it, namely modern Fortran. Once you do, you can then make an informed choice, instead of behaving like an immature language zealot.
Here are two places you should start looking:
http://en.wikipedia.org/wiki/Fortran_95_language_features#Arrays_2
http://en.wikipedia.org/wiki/High_Performance_Fortran
(The Fortran code on libdecomp.org is cringe-inducing and inefficient.)
And, FWIW, I'm primarily a C++ programmer, because that's what the market demands, not a Fortran programmer, but at least I know my tools and their limitations.
If you use C, assembly, or Java "correctly", you can usually match Fortran code. That is entirely not the point.