A C++ Library That Brings Legacy Fortran Codes To Supercomputers 157
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."
Code... (Score:4, Informative)
Re:Code... (Score:3)
It really does lower one's opinion towards the author. If I read TFAs, I wouldn't read this one.
Re:Code... (Score:3, Insightful)
Re:Code... (Score:3)
Not to mention the fact that the author has erased history (well, the summary implies the author has erased history - I haven't read TFA) because the Cray 1 had a vector processing unit and a specially designed compiler to make use of it, and the compiler was for Fortran. This was in 1978 when C++ didn't even exist.
Re:Code... (Score:4, Informative)
actually, "codes" is common usage amongst researchers and has been since at least the 1970s.
most of them are not programmers or geeks or computer scientists, they're researchers or academics or post-grad students who happen to do a little programming or simply use someone else's "codes".
it used to make me cringe every time i heard it when working with academics and researchers and on HPC clusters, but then i got used to it and stopped caring.
and, really, they're not interested in a lecture or why it's a dumb usage of the word. they've got stuff they want to get done ("codes to run") and don't give a damn.
Author here. (Score:4, Informative)
Re:Author here. (Score:2)
I guess I was mistaken in assuming the computer-science way of thinking about the concept of "code" (vs. "program", "algorithm", or "function", which are definitely discrete, countable things) should extended to other fields.
As a side note, although it is true that my nickname was originally a misspelling of "gigahertz", I chose it while I was young, and as a non-native English speaker, my knowledge of the language was lacking. I have been perfectly aware of that fact for a long time, but I chose to maintain the uncorrected version, both for the habit, and because I found it amusing that "herz", when read in German, means "heart".
Re:Author here. (Score:2)
"I guess I was mistaken in assuming the computer-science way of thinking about the concept of "code" (vs. "program", "algorithm", or "function", which are definitely discrete, countable things) should extended to other fields."
You were not mistaken, the world just grows more poorly educated. Yesterday's illiteracy is today's literacy. Making "code" synonymous with "program" and subsequently requiring a plural form serves no purpose, sounds stupid, and is stupid.
No doubt others wish to "commentate" on the matter so I step down from my soap boxen.
Re:Author here. (Score:3)
I'd suggest you don't be so pious. I'm for protecting the language as much as anyone else but ultimately it evolves. I don't think this is really about the people employing numerical techniques in science becoming "more poorly educated"; I think it's about your field branching out and attracting new jargon and new uses for the old jargon. It's just what happens.
As it happens, I've spent close to ten years in academia where we build "codes" (typically in Fortran -- 90 or more recent if you were lucky; 77 if you weren't) to solve problems. I have since moved into professional development, chiefly in C++ and occasionally in C#. The use of the spoken language changes and the two fields have different ways to express the same concepts. Ultimately I don't really see a major problem with this.
All that said, misuse the word "corn" and I begin to get extremely irritated so I probably shouldn't be so pious myself... :)
[In British English "corn" doesn't mean maize, it means wheat, or occasionally barley -- more accurately, it means the chief arable crop of an area. When English speakers settled North America, that chief arable crop was maize, hence the American usage. What annoys me isn't Americans calling maize "corn" -- which is entirely valid in both North America and in their dialect of English -- but rather the *British* thinking that corn is maize. It isn't, it's wheat. I also wish they'd get off my God damned lawn.]
Re:Author here. (Score:2)
Re:Author here. (Score:2)
Calling corn 'wheat' a default is a good way of putting it - it was what I was trying to get across in more words. "Corn" is ultimately related to "Kernel" and does certainly come from "seed", "grain". But the language evolved so that now it's a catch-all for grains, and wheat by default across most of Europe. Of course, I want the kids off my lawn and the language to stop evolving ;)
Re:Author here. (Score:2)
I had some common taters for dinner.
Re:Author here. (Score:2)
You were not mistaken, the world just grows more poorly educated. Yesterday's illiteracy is today's literacy.
Forsooth, good sirrah, thou hast spake sagely, and shewn thyself more wise that thy wyrd wurds should haue me think.
Re:Author here. (Score:2)
Re:Code... (Score:2)
never worked in the field of high performance numerical methods?
Re:Code... (Score:2)
Obviously not. Even after reading the other replies, and realizing that I was partially wrong, I still can't help but feel that it sounds wrong.
The concept of code, to me, is a collection of statements, expressions, functions, packages, etc. Like a bowl of rice, it makes no sense to count the grains for themselves. I can accept that other people understand it differently, but it's not easy not to feel that they are doing it wrong...
Re:Code... (Score:2)
Re:Code... (Score:4, Insightful)
Oh now, that's a bit harsh. Programming in Fortran isn't something done because people are afraid of work. I genuinely get tired of the incessant Fortran-bashing by people who -- in my experience, at least -- have almost never, if ever, actually used the language or seen why other people do. In most cases they seem to be repeating jokes their lecturers made about the language, jokes that were first written back when FORTRAN 77, with those stupid capitals and all, was the dominant form.
Now, I'm very much not a fan of F77. In fact, I hate the language. It's clunky and decrepit and not suited for modern programming practices. But it's easy to call from later Fortran standards, and each one has vastly improved the situation. Fortran 2008 is a genuinely nice language. True, it's not OO - though you can force it to act almost as if it is - but not everything has to be forced into OO. What it is is extremely good for numerical work, and dealing with arrays in particular in Fortran is a dream after, say, C, or even C++11. The fact it calls F77 routines without effort or pain also helps, since there genuinely is a vast body of code still in F77. (The oldest I came across was F66, ported directly from Fortran IV. Now that really did need to be rebuilt in something approaching a sane language.)
I'm not saying F2008 is "better" than either C or C++11 -- that's a meaningless statement. But there are things that make it a very nice language to use, and other things -- character strings, I'm looking at you -- that make it distinctly unpleasant. Same as any other language, really.
Re:Code... (Score:2)
True, it's not OO - though you can force it to act almost as if it is - but not everything has to be forced into OO.
That's an almost meaningless statement, unless you define what is "OO" (ten programmers will give you twelve different definitions for that).
Also, the modern replacement for Fortran ought to be Fortress. (Or, more properly, a language using similar algebraic techniques to improve the HPC programming experience, seeing as the original Fortress effort has wrapped up.)
Re:Code... (Score:2)
"That's an almost meaningless statement, unless you define what is "OO" (ten programmers will give you twelve different definitions for that)."
Very true. In this exact context I'm meaning an object containing functions that are contained within its namespace. There's almost certainly actually a way to do that in modern Fortran but I'm not aware of it, and instead I use modules as a rough analogue of a class and select the functions from them that I want to use in a particular method. (I can also get around quite a bit of the issue by overloading the function names in the interface, if it seems that important. Normally it doesn't, to be honest.)
Re:Code... (Score:2)
To use the rice analogy, you would say "bowls of rice", not "rices".
What, you mean like that ignorant error we all make of counting fish, cows etc?
Re:Code... (Score:2)
it is correct though
similar to how moneys and monies are both correct plurals of money, even though in America people use money to refer to both singular and plural but they should recheck the dictionary.
codes is interchangeable as well http://www.thefreedictionary.com/code [thefreedictionary.com]
Re:Code... (Score:3)
Re:Code... (Score:2)
...like rice, is not countable. At least not since I learned the word.
It's a shiboleth of physicists and lousy journalists.
Re:Code... (Score:2)
"Secret codes" or "cipher codes" are countable. So are "weather simulation codes".
Re:Code... (Score:2)
Re:Code... (Score:2)
Re:Code... (Score:3)
Code is a mass noun, and it's number is indeterminate, neither singular nor plural.
Codes code as peoples people (Score:3)
I, too, work in HPC computing, and while I found "codes" very jarring to begin with, I've learned to live with it. I am not sure the "code" vs. "codes" issue it is more grammatically problematic than "people" vs. "peoples". A people (countable) is made up of people (uncountable). Similarly "a code" (countable, but nonstandard) is made up of code (uncountable). Personally I would use "a program" or "a library" instead of "a code", though.
Another related issue is whether "data" is countable or not. I'm used to it being uncountable, with there being more or less of it, but not "several data". But scientific journals in my field prefer the countable version "a datum", "several data", which is arguably more historically correct. That, too, took some getting used to.
Re:Code... (Score:2)
Re:Code... (Score:2)
Very limited scope (Score:3)
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'.
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.
Re:Very limited scope (Score:3)
Re:Very limited scope (Score:2)
In regard to:
You really think that sentence was written by a person with a tenuous grasp of the English language. Seriously?
Re:Very limited scope (Score:2)
You really think that sentence was written by a person with a tenuous grasp of the English language. Seriously?
Tenuous grasp, no; but non_native != tenuous_grasp. The blog's at a German university. The choice of "marry" over "combine" is slightly unusual, as the idea of choice falling on something. It's very, very good. But it's still most likely not his first language, so pedantic polemics are uncalled for.
Re:Very limited scope (Score:2)
Very limited indeed (Score:5, Informative)
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.
How do I put this... (Score:2)
I think I speak for many geeks when I say....
KHHHAAAAAAAAAAAAAANNNNNN!!!!
That is all.
bigger problems (Score:2)
Seems to me that there are bigger problems when porting Fortran code to C++, like lack of a multidimensional array type in C++, lack of all the other Fortran libraries, and the fact that Fortran code usually still seems to give faster executables than comparable C++ code on numerical applications.
Re:bigger problems (Score:2)
fortran code usually still seems to give faster executables than comparable C++ code on numerical applications
I don't think this is true anymore. C++ is pretty much the only language that has BLAS libraries that can actually beat the fortran ones. The latest C++ template libraries are using SSE/etc vector intrinsics and are capable of meeting if not exceeding the fortran performance for many applications.
But, if you have a bunch of code in fortran, its probably not worth the trouble to convert it.
Re:bigger problems (Score:2)
Lots of existing code is in Fortran and is easiest interfaced in Fortran. In addition Fortran 2008 included things like concurrency in the language that C++ only got in 2011 as a part of the standard library.
The theme of this project is more about "my language (C++) the one true language" than reality.
Re:bigger problems (Score:2)
Why would any Fortran compiler be using a slower BLAS implementation than the C compiler?
Hand-tuned C code is "capable of meeting if not exceeding the fortran performance for many applications", but that doesn't make C a good numerical programming language. The question is whether normal, straightforward numerical code runs faster when written in one or the other language, not whether you can produce fast code if you invest enough time in writing it.
The trick is to avoid solving the bigger problems (Score:2)
We're using Boost Multi-array [boost.org] as a multi-dimensional array, so that's not really a problem. And since we call back the original Fortran code users are still free to use their original libraries (some restrictions apply -- not all of these libraries will be able to handle the scale of current supercomputers).
Regarding the speed issue: yeah, that's nonsense today [ieee.org]. It all boils down writing C++ in a way that the compiler can understand the code well enough to vectorize it.
Re:The trick is to avoid solving the bigger proble (Score:2)
You never want a compiler to vectorize code. You want interfaces to vectoring hardware that you use to vectorize operations on your data. Just like you don't want compilers to provide multidimensional arrays - memory isn't multidimensional, so there's no natural layout. Instead you implement the arrays you need - even if they look the same the complexity contract and implementation is completely different for statically dimensioned (e.g. template params in C++) vs dynamically dimensioned (can be resized); sparsely populated either an entire row in a dimension, by specific dimension, or by any dimension (for instance only have data in rows 0, 5, 10383484387373, colums -4948484, 0, 338383 - implying sparsely populating only the intersecting cells); where indexes are arbitrary types (say complex), etc. NONE of this has a natural representation. Just like vectored operations in a NUMA architecture require careful data management for maximum throughput - so if you want to apply this to a sparse data set for instance you need to think through how this is to be done rather than just think a compiler can spit it out for you (other than in the most trivial demos that lack real-world requirements).
Re:The trick is to avoid solving the bigger proble (Score:2)
I most certainly do.
There is a natural layout that handles 99% of all numerical needs. Numerical programmers understand it, and so do compilers.
You listed a bunch of exceptional cases that should indeed be handled by libraries. But not to support common cases well because of exceptional cases is stupid.
Re:The trick is to avoid solving the bigger proble (Score:2)
Boost Multi-array doesn't support most modern Fortran array features, so it's useless for porting modern Fortran code to C++: you end up having to rewrite most of the code from scratch.
That just shows that with enough effort, you can create efficient special purpose libraries in C++; of course you can. The question is whether straightforward, boring numerical code compiles into fast executables. If you write it using Boost multi-array, it ends up being much slower (not to mention more tedious) than equivalent Fortran code.
FUD (Score:2)
Re:FUD (Score:4, Informative)
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 [wikipedia.org]
http://en.wikipedia.org/wiki/High_Performance_Fortran [wikipedia.org]
(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.
QED (Score:2)
So you said Fortran codes we faster than C++ codes and now that's not the point any longer as they really aren't? Great, thanks!
The links you provided show that Fortran has some convenience functions for selecting parts of arrays and applying arithmetics to them. What I didn't see is anything you can't so with Boost Multi-Array and Boost SIMD [meetingcpp.com].
Re:QED (Score:2)
I said no such thing; that doesn't make any sense. What I said is:
Boost Multi-array doesn't support most modern Fortran array features, so it's useless for porting modern Fortran code to C++: you end up having to rewrite most of the code from scratch.
and
That just shows that with enough effort, you can create efficient special purpose libraries in C++; of course you can. The question is whether straightforward, boring numerical code compiles into fast executables. If you write it using Boost multi-array, it ends up being much slower (not to mention more tedious) than equivalent Fortran code.
Yes, and in addition to that, the compilers know how to do kick-ass optimization on these "convenience functions", vectorize these expressions, and (depending on the compiler) parallelize them, for up to seven dimensions and any in-memory layout, stride, and indexes. In addition, there is a simple and straightforward notation for distributing those computations in Fortran and HPF.
And if all of that were so easy to implement, there would already be C++ libraries doing it, but unfortunately there aren't. Boost multi-array certainly does none of those things. Even if these features weren't so useful for writing readable, high performance numerical code (and they are), they are essential for porting modern Fortran code to C++, because if there isn't anything equivalent, a port requires all of that to be rewritten by hand with loops.
(In addition, your Fortran example and your use case for LibGeoDecomp are piss-poor, but that's a separate issue.)
Re:QED (Score:2)
Sorry, I got overexcited and did see something in your post that apparently wasn't there.
And yet I don't buy into this "OMG, C++ is either clumsy or slow compared to Fortran" FUD (I hope I'm paraphrasing it correctly this time). For a certain (perhaps smallish) domain LibGeoDecomp is such a library which makes it easy to write short, yet (nearly) optimal code with C++.
I don't doubt though that there are use cases where it's hard to come up with a good C++ solution while Fortran would outperform it in both, speed and simplicity.
Re:bigger problems (Score:2)
Its code not codes FFS (Score:2)
Re:Its code not codes FFS (Score:2)
Unlike Ruby (Which I can develop code in VERY quickly) my C++ is type-safe and I can catch a lot of smile programming errors at compile time. I appreciate not finding run-time bugs in my deep space probe when it's 80 million miles from earth. And yes, I also write unit tests for my libraries.
Unlike Java, my C++ code doesn't require a gigantic VM to run in, I know exactly when my resources are being freed, I don't have to worry about someone else on the team using RTTI bullshit (I've never seen an instance of RTTI that wasn't indicative of a terrible design. Would welcome good examples,) and I can revert to the C standard library for full control of the hardware. If the OS can do it, the C standard library probably has a function for it. Mostly I'm just more comfortable in the language, though. In a lot more java-using applications, the decision to use Java was the wrong one. I've had to support a few of those. It's left me with a permanent distaste for the language. A distaste which Oracle does not help with its shenanigans (Attempting to claim copyright on APIs and trying to install some fucking useless toolbar every time it patches my system.)
Note that a lot of this IS subjective opinion and not really a critique of one language or the other. I can program in anything, if I need to. I just happen to like C++. I've posted what I consider to be respectably nifty libraries to github and already have several more planned. It's not like someone can't look at my source code and decide for themselves if it's crap or not.
Re:Its code not codes FFS (Score:3)
I have had conversations with some of my friends who work on the peta-scale clusters and thought much the same as you. But, it turns out, when you're working with that level of system, you're probably addressing some small part of a much, much larger problem that has been largely solved. The existing code that performs 99.9% of your task is written in Fortran and actively developed by a very successful team of researchers. Attempting to rewrite the working, debugged, code so you can work in your favorite language today is not only impossible, but would likely get you removed from the team.
Re:Its code not codes FFS (Score:2)
Thing about those old systems, they typically weren't written by dumbasses. Most of my career has been following along behind dumbasses cleaning up at them. It's lucrative work, and I'm never hurting for something to do. Every so often I happen upon a system that was actually written by engineers and it's usually delightful when I find one.
Given the ease with which you snap to a judgment, you must be a fucking amazing programmer, so let's see your open source repos. My home page is set to mine.
Re:Its code not codes FFS (Score:3)
Re:Its code not codes FFS (Score:3)
That's because you aren't doing development on computationally expensive simulation codes that run on supercomputers. Because then you would use FORTRAN. C++ is such a memory hog, and the memory overhead scales with the number of processors. In FORTRAN, you only allocate what you need to use, and that's important when working with large arrays. Java and Ruby are out of the question.
FORTRAN is not obsolete, because there are currently no other languages that can fill the role. When running simulations that take 100000+ cpu-hours, it's worth the extra coding effort to write it in FORTRAN. Assembly language isn't being considered because generally, these codes need to run on different supercomputers which all have unique architecture. Therefore, optimizing compiling scripts exist for each supercomputer for use with FORTRAN.
Re:Its code not codes FFS (Score:2)
C++ is such a memory hog, and the memory overhead scales with the number of processors.
What on earth are you talking about?
Re:Its code not codes FFS (Score:2)
Re:Its code not codes FFS (Score:2)
Re: Its code not codes FFS (Score:4, Informative)
Please don't learn FORTRAN, learn Fortran instead. (For the pedantic, all caps is F77. Normal caps is F90 and later.)
Fortran works fine with MPI (Score:5, Informative)
...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.
Agreed. (Score:2)
Re:Fortran works fine with MPI (Score:2)
You only have to rewrite it a *little* bit (Score:5, Insightful)
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.
Did you read TFA? (Score:2)
Re:Did you read TFA? (Score:2)
And so on the basis of one example you're willing to take their word that changing languages doesn't require re-debugging the entire program?
My, my, but you are naive, aren't you?
Re:Did you read TFA? (Score:2)
Even when you change compilers but keep the same source code you have to redebug complex FORTRAN code, due to idiosyncracies in implementations over the years.
Re:Did you read TFA? (Score:2)
Sometimes you get new bugs even with the same compiler, just because you changed optimization flags for the build.
No, I'm taking MY word for it. :-) (Score:2)
Sorry, I should probably have added a disclaimer that I'm involved in the development of the library as my signature apparently doesn't make it obvious enough: I'm the project lead.
So far we've built about a dozen application with LibGeoDecomp, including porting a dozen large scientific codes towards it. You're right that porting a code usually involves debugging. But that's inevitable when parallelizing a previously sequential code anyway. We don't claim to do magic, we just have some cool tricks up our sleeves. And that's a Good Thing(tm). Because those who claim to cast magic usually disperse just b/s while clever tricks can save you weeks (months even) of work. Here is what you don't have to do if you use LibGeoDecomp:
As said, parallelizing a sequential code will almost always involve some sort of debugging, no matter which tool you use. But the library also brings a couple of facilities to ease that transition: 1. you can first adopt the SerialSimulator [libgeodecomp.org] which performs no parallelization at all, but allows you to check the data transfer and callbacks. 2. you can then transition to those parallelization which run on a single node only (e.g. the CacheBlockingSimulator [bitbucket.org] or the CudaSimulator [bitbucket.org]) to check that there are no race conditions before (3.) you finally more to large scale systems using e.g. the HiParSimulator (used for full system runs on JUQUEEN, an IBM BG/Q and ATM the fastest European machine) or the HpxSimulator (used for runs on TACC's Intel Xeon Phi equipped Stampede; BTW: it's built on HPX [lsu.edu], a parallel runtime to C++). 4. Finally you can piggy-back the TestCell [bitbucket.org] onto your model, which will use checksums to validate the data the library gives back to your code.
Targeted at Managers (Score:2)
Someone has some legacy Fortran code and a task of modifying it. There are two approaches: Port it or work on the existing source. Porting it allows for hiring from a very large (but shallow*) pool of programmers familiar with 'current' languages like C++. Working with the existing code means having to locate resources in a much smaller market. The former are cheap. The latter much more expensive. What to do?
*Good programmers can probably pick up a book and teach themselves Fortran pretty easily. But even in the C++ world, these people are more highly paid. There exists a large supply of people who know one language, but not the concepts of programming in general and are not cross trainable. These people work cheap**.
**Putting this class of people on such a project probably signals disaster.
Recent experience with old code (Score:2)
Reminds me of a recent experience writing a new system to replace a legacy system.
A key part of one of the homegrown network protocols was a CRC. This sounds OK, but the implementation was wrong. I spent a lot of time trying to reverse-engineer just what the original engineers had implemented. The fact that it was written in ADSP2181 assembler didn't help. It had never been an issue before because both ends of the link used the same wrong implementation, so the errors cancelled out.
I ended up writing an instruction-level simulation of the ADSP2181 processor (only needed a handful of instructions) and executing the original code directly. It works fine. Performance isn't an issue, though moving from a 33 MHz DSP chip to an eight-core 2.8 GHz box certainly helps in that department. :-)
...laura
interesting tool, misleading summary (Score:5, Interesting)
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.
In my personal experience... (Score:3)
In my personal experience...
Most of the physics code in FORTRAN that I've dealt with are things like relativistically invariant P-P and N-P particle collision simulations in order to test models based on the simultaneous solution to 12 or more Feynman-Dyson diagrams. It's what was used to predict the energy range for the W particle, and again for the Higgs Boson, and do it rather reliably.
The most important part of this code was reproducibility of results, so even though we were running Monte Carlo simulations of collisions, and then post-constraining the resulting pair productions by the angles and momentum division between the resulting particles, the random number stream had to be reproducible. So the major constraint here was that for a reproducible random stream of numbers, you had to start with the same algorithm and seed, and the number generation had to occur linearly - i.e. it was impossible to functionally decompose the random number stream to multiple nodes, unless you generated and stored a random number stream sufficient to generate the necessary number of conforming events to get a statistically valid sample size.
So, it was linear there, and it was linear in several of the sets of matrix math as it was run through the diagrams to filter out pair non-conforming pair production events.
So we had about 7 linearity choke-points, one of which could probably be worked around by pre-generating a massive number of PRNG output far in excess of what would be eventually needed, and 6 of which could not.
The "add a bunch of PCs together and call it a supercomputer" approach to HPC only works on highly parallelizable problems, and given that we've had that particular capability for decades, the most interesting unsolved problems these days are not subject to parallel decomposition (at least not without some corresponding breakthroughs in mathematics).
I converted a crap-load of FORTRAN code to C in order to be able to optimize it for Weitek vector processors plugged into Sun hardware, including the entire Berkeley Physics package, since that got us a better vector processor than was on the Cray and CDC hardware at Los Alamos where the code was running previously, but adding a bunch of machines together would not have improved the calculation times.
Frankly, it seems to me that the available HPC hardware being inherently massively parallel has had a profound effect on constraining the problems we try to solve, and that there are huge, unexplored areas that are unexplored for what amounts to the equivalent of someone looking for their contact lens under the streetlight, rather than in the alley where they lost it, "because the light's better".
HPC is just a niche market, too (Score:2)
You're right: the current compute architectures we see in HPC are geared at data parallel problems of massive size. Clock speeds are stagnating, sometimes even stepping down (e.g. NVIDIA Kepler has its cores actually clocked slower that Fermi with its hot clock for the shaders). Your description sounds like you'd benefit from a singular core which is tuned for single thread performance (e.g. with really big caches, a large out of order execution window) and runs at 5-10 GHz (which might require liquid nitrogen cooling).
But then again this is another niche, probably even smaller than the current HPC market, so it might not be commerially viable to develop products for it.
Re:In my personal experience... (Score:2)
See here for a parallel way to deal with your random number generation problem:
http://www.stat.osu.edu/~herbei/GPU/RNG.pdf [osu.edu]
Thanks; read the paper; it presents three methods, 2 of which are unsuitable for parallel decomposition to an arbitrary number of CPUs (the Mersenne Twistor is not suitable to thread level decomp.), and one of which where you have to really carefully define you m(i). Changing algorithms isn't really an option, unless you are willing to rerun all of your historical computations, since unles you use the same PRNG, there is no guarantee of precise reproducibility, which is one of the issues here.
I think it'd be easier, with today's storage capabilities, to just pre-generate them, but that doesn't get around the dependent matrix operations problems which make it a linear computation after that.
But aside from that, Mrs. Lincoln? (Score:2)
That's not what I call "limited". More like a rewrite, or at least a salvage operation.
Re:It never ceases to amaze me (Score:4, Insightful)
Re:It never ceases to amaze me (Score:3, Insightful)
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.
Re:It never ceases to amaze me (Score:2)
A pedantic note - it hasn't been called "FORTRAN" since Fortran 90 was introduced. Otherwise it's nice to see people defending it for scientific applications :)
Re:It never ceases to amaze me (Score:4, Insightful)
Re:It never ceases to amaze me (Score:2)
And the funny thing is, game developers who are designing game engines in C++ for multi-core systems also use scripting languages like LUA at the high level. Then you have so many ways of doing parallel processing of arrays in C++; STL vectors (foreach), Intel TBB, Intel ABB, Boost, pthreads, and many others. I can't imagine what it would be like trying to bolt together a dozen or more different utility libraries each using their own favorite blend of parallel processing API's.
I guess Fortran is like the Python language in that there is only one way of writing everything.
Re:It never ceases to amaze me (Score:5, Funny)
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.
Re:It never ceases to amaze me (Score:2)
Re:It never ceases to amaze me (Score:2)
Very true. For my own comfort I tended to stick within pure Fortran programs - I'm still more comfortable in Fortran than in C or C++ - but there were things that were better to do elsewhere, particularly where I had access to a library that I much preferred (say, in C, which happened quite a bit) to what I easily had available in Fortran. Sure, I could have gone hunting but it was a lot easier to build a trivial wrapper around the C library and just call that. I can't actually remember why I didn't like the Fortran interfaces for the GSL that were around but I ended up building wrappers around quite a bit of that at various times.
Re:It never ceases to amaze me (Score:3)
In Fortran you don't. Fortran has the mathematically expected parallel constructions built into the language, and the compiler directives commonly used before things are entirely in the language were reasonably standard.
I think Fortran is very good for quantitative programming and I regret that in my commercial enterprise it is essentially forbidden as alien.
Re:It never ceases to amaze me (Score:2)
Re:It never ceases to amaze me (Score:2)
Yes you can, since Fortran 2003.
Re:It never ceases to amaze me (Score:2)
There is nothing you can do in fortran that can't be done better in C++
Yeah? Well there's nothing in C++ that can't be done better in assembler.
Old and kludgy makes it harder to port. (Score:3)
Not only does it cost a LOT to port this stuff and risk errors in doing so, but the cruftier it is the harder (and more expensive and error-prone) it is to port it.
If, instead, you can get the new machines to run the old code, why port it? Decades of Moore's Law made the performance improve by orders of magnitude, and the behavior is otherwise unchanged.
If you have an application where most of the work is done in a library that is largely parallelizable, and with a few tiny tweaks you can plug in a modern multiprocessor-capable library and run it on a cluster, you get another factor of almost as-many-processors-as-I-decide-to-throw-at-it, with small effort and negligible chance of breaking the legacy code.
What a deal!
And it's one less reason to touch the tarbaby of the rest of the working legacy code.
Let the COMPUTER do the work. People are for setting it up - with as little effort as practical - and moving on to something else that is important and can't yet be automated.
Eventually somebody will teach the computers to convert the Fortran to a readable and easily understandable modern language - while both keeping the behavior identical and highlighting likely bugs and opportunities for refactoring. Until then, keeping such applications in the legacy language (unless there's a really good reason to pay to port them) is often the better approach - both for economy and reliability.
Re:Old and kludgy makes it harder to port. (Score:2)
"Eventually somebody will teach the computers to convert the Fortran to a readable and easily understandable modern language - while both keeping the behavior identical and highlighting likely bugs and opportunities for refactoring."
That language will likely be Fortran 2008 or 2015...
Re:Old and kludgy makes it harder to port. (Score:2)
Re:Old and kludgy makes it harder to port. (Score:2)
I've long been tempted to get a .net compiler for Fortran. That would make it *really* easy to build some ugly Java.
Re:It never ceases to amaze me (Score:2)
please go back to your java and c++ world and leave Fortran alone - you don't know the first thing about Fortran or Fortran compilers.
Re:Modern Fortran (Score:3)
more than adequate, Fortran is still the most optimizable language for high performance numeric computation, moreso than C and derived languages
Re:Modern Fortran (Score:2)
Fortran is the most used and therefore the biggest target for continued improvement. Saying it is the "most optimizable" means nothing. As a tools company you aren't going to focus on what none of your customers do.
x86 is the most modern high-performance instruction set by your reasoning. Sometimes alternatives are just not sufficiently compelling, that doesn't mean they are inferior.
Re:Modern Fortran (Score:2)
Re:Modern Fortran (Score:2)
Efficient software is more than good assembly (Score:2)