×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A C++ Library That Brings Legacy Fortran Codes To Supercomputers

timothy posted about 7 months ago | from the fort-went-that-way dept.

Programming 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

157 comments

Code... (3, Informative)

gigaherz (2653757) | about 7 months ago | (#44912119)

...like rice, is not countable. At least not since I learned the word.

Re:Code... (2)

Nerdfest (867930) | about 7 months ago | (#44912133)

It really does lower one's opinion towards the author. If I read TFAs, I wouldn't read this one.

Re:Code... (3, Insightful)

John Burton (2974729) | about 7 months ago | (#44912301)

I couldn't agree more. Although the word "codes" is usually a red flag not to bother reading any more in any article or question

Re:Code... (2)

jeremyp (130771) | about 7 months ago | (#44912427)

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... (1)

Anonymous Coward | about 7 months ago | (#44912165)

in hpc the convention is that while code is indeed a formless pile

a code is also a discrete and countable thing - an application or package, as in we've managed
to port 3 big codes to the new machine

none of which explains why, of all the various communication and decomposition libraries that
sit under such codes, this one got posted

Re:Code... (0)

beelsebob (529313) | about 7 months ago | (#44912655)

No, simply wrong. Code is a plural noun. Just like sheep is a plural noun, and rice is a plural noun. The word codes refers to the plural of a completely different meaning of code –i.e. cyphers.

Re:Code... (2)

Livius (318358) | about 7 months ago | (#44912695)

Code is a mass noun, and it's number is indeterminate, neither singular nor plural.

Codes code as peoples people (2)

amaurea (2900163) | about 7 months ago | (#44912859)

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... (0)

Anonymous Coward | about 7 months ago | (#44912359)

It's a deep tradition in the numeric community to speak of "codes". I think it sounds stupid too, but everyone does it.

Re:Code... (1)

mjwalshe (1680392) | about 7 months ago | (#44912963)

Not where i come from it isn't and my first job was in the math modeling section of a world leading rnd organization

Author here. (3, Informative)

gentryx (759438) | about 7 months ago | (#44912479)

The IEEE and Los Alamos National Laboratory seem to have a different opinion [google.com] on this. And even the Oxford dictionary knows the use of codes [slashdot.org]. But surely those guys can't even spell gigahertz.

Re:Author here. (1)

gigaherz (2653757) | about 7 months ago | (#44912547)

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. (1)

dfghjk (711126) | about 7 months ago | (#44912671)

"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. (2)

boristhespider (1678416) | about 7 months ago | (#44912789)

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. (1)

gentryx (759438) | about 7 months ago | (#44912813)

Just to add another twist: even as an English native speaker I would not be surprised if you spelled Hertz wrong since it's a German name, and because Herz and Hertz are pronounced identically in German, it's even a common misspelling in Germany, too. :-)

Re:Author here. (0)

Anonymous Coward | about 7 months ago | (#44913095)

It doesn't help that a Herz (heart) beats at 1 Hertz, so it would even be a plausible etymology. :-)

Re:Author here. (0)

Anonymous Coward | about 7 months ago | (#44912781)

giga-Hertz, you insensitive clod.

Re:Code... (0)

Anonymous Coward | about 7 months ago | (#44912535)

In scientific computing, the overwhelmingly accepted term is "a code" to refer to what other fields of computing refer to as an "application" or "program". Language evolves, and each discipline comes up with its own common terms and jargon. Deal with it.

Re:Code... (1)

rubycodez (864176) | about 7 months ago | (#44912543)

never worked in the field of high performance numerical methods?

Re:Code... (1)

gigaherz (2653757) | about 7 months ago | (#44912569)

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... (0)

dfghjk (711126) | about 7 months ago | (#44912707)

Why concern yourself with the opinions of those still stuck using Fortran because they're afraid of work? They are doing it wrong. Language is useless without agreed upon usage.

To use the rice analogy, you would say "bowls of rice", not "rices". Now, if enough stupid people or even an entire community intentionally made that error, it may well become adopted as correct usage. It would still be ignorant.

Understand that scientists and researchers are not programmers and don't know any better.

Re:Code... (3, Insightful)

boristhespider (1678416) | about 7 months ago | (#44912891)

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... (1)

K. S. Kyosuke (729550) | about 7 months ago | (#44913235)

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... (1)

boristhespider (1678416) | about 7 months ago | (#44913249)

"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... (1)

jythie (914043) | about 7 months ago | (#44913593)

That is one of the things that happens when multiple disciplines overlap, sometimes their jargon does not always match up.

Re:Code... (0)

Anonymous Coward | about 7 months ago | (#44912659)

In scientific computing, a "code" is a software package. Abaqus and Ansys are finite element "codes".

Re:Code... (1)

Cito (1725214) | about 7 months ago | (#44912739)

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... (0)

Anonymous Coward | about 7 months ago | (#44912831)

No, because a program is not "a code", it is simply "code". Multiple programs are not "multiple codes", they are simply "code". Monies (never "moneys", unless you're attempting to exemplify the illiteracy and progression of stupidity mentioned previously) is valid because money and currency are directly interchangeable terms. When speaking of a items of either, they may be prefixed with counting articles ("a", "some", "many", "one", "two"). Code as a term describing computer programs is not prefixed with a counting article, and is therefore not pluralized.

Re:Code... (2)

Thomasje (709120) | about 7 months ago | (#44913161)

I studied math in college, and many numerical algorithms textbooks refer to software as "codes". It seems to be common practice in the computational mathematics world. I assume it goes back to the days before Fortran, before high-level languages in general, when source code literally consisted of a series of codes.

Re:Code... (1)

K. S. Kyosuke (729550) | about 7 months ago | (#44913201)

...like rice, is not countable. At least not since I learned the word.

It's a shiboleth of physicists and lousy journalists.

It never ceases to amaze me (0, Funny)

Anonymous Coward | about 7 months ago | (#44912131)

how tenaciously researchers cling to their old, cludgy fortran code.

Re:It never ceases to amaze me (3, Insightful)

Mitchell314 (1576581) | about 7 months ago | (#44912197)

In old codes, you're already familiar with the existing quirks and bugs, and the base is heavily patched up from years of debugging.

Re:It never ceases to amaze me (3, Insightful)

Anonymous Coward | about 7 months ago | (#44912239)

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 (0)

Anonymous Coward | about 7 months ago | (#44912305)

Yes, exactly.

FORTRAN has a syntax that was designed for scientific and engineering applications. And as the parent pointed out, compiler design has improved dramatically over the decades.

Spending all that time and effort to change another language just to have a different different syntax makes no sense. It gets you nothing and that time is better spent on actual work - or free time.

And when you think of it, there hasn't been any improvements in programming languages since FORTRAN or COBOL.

Really those languages were to move programmers away from assembly and machine code. And today's "modern" languages really don' t offer much more - except, I guess, more abstraction and it's subsequent overhead.

Re:It never ceases to amaze me (1)

boristhespider (1678416) | about 7 months ago | (#44912901)

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 (0)

Anonymous Coward | about 7 months ago | (#44912673)

I'm a scientific software developer an have written and maintained a good bit of Fortran 77 and 90 code, but never any modern Fortran. I could never figure out what good websites or books to reference even to learn about the fancier features of modern Fortran. I can see that it's used in some areas, but it's got little use in mine (solid mechanics, fluid mechanics).

Re:It never ceases to amaze me (3, Insightful)

mjwalshe (1680392) | about 7 months ago | (#44912403)

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.

Re:It never ceases to amaze me (1)

mikael (484) | about 7 months ago | (#44912897)

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 (4, Funny)

boristhespider (1678416) | about 7 months ago | (#44912953)

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 (1)

jythie (914043) | about 7 months ago | (#44913627)

Esp given how easy it is to link Fortran to C, C++, and ObjC. Granted it has been years since I worked with the stuff, but the last project I was on we jumped between Fortran, C and C++ depending on which had better stuff for any particular part of the program, and GCC compiled them all down into a single binary.

Re:It never ceases to amaze me (1)

boristhespider (1678416) | about 7 months ago | (#44913689)

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 (2)

mbkennel (97636) | about 7 months ago | (#44913203)

" 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."

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 (0)

Anonymous Coward | about 7 months ago | (#44913401)

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)

There is nothing you can do in fortran that can't be done better in C++

There are tons of things that can be done in C++ that can't be done in fortran. For instance, in C++ I can put a function pointer in a type. You cannot put a function pointer in a derived type in Fortran.

Re:It never ceases to amaze me (1)

jythie (914043) | about 7 months ago | (#44913637)

While there are some add on libraries that can do 'ok', Fortran is generally much better then C or C++ at handling numbers. In applications I have worked on that used both languages, generally you only let the C++ code handle the data when it didn't have to be all that accurate, such as sending it to the UI. But for calculations you would keep it in Fortran.

Old and kludgy makes it harder to port. (2)

Ungrounded Lightning (62228) | about 7 months ago | (#44912731)

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. (1)

boristhespider (1678416) | about 7 months ago | (#44912979)

"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. (1)

jythie (914043) | about 7 months ago | (#44913645)

Well, you can always decompile the Fortran into Java.....

Re:Old and kludgy makes it harder to port. (1)

boristhespider (1678416) | about 7 months ago | (#44913669)

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 (1)

Lawrence_Bird (67278) | about 7 months ago | (#44913729)

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.

Very limited scope (2)

RoverDaddy (869116) | about 7 months ago | (#44912203)

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'.

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 (2)

Mitchell314 (1576581) | about 7 months ago | (#44912271)

AFAIK a lot of simulation problems are centered around 'update node based on neighbors', like particulate dispersal or flux.

Re:Very limited scope (1)

Zero__Kelvin (151819) | about 7 months ago | (#44912319)

FTA:

"My idea for this post was to take an simple 3rd party program and try to marry it with LibGeoDecomp while preserving as much as possible of its original code and structure. The Hello World equivalent for computer simulations is Conway's Game of Life. My choice fell on this code, kindly provided by KTH, Sweden. The code has several advantages:"

In regard to:

"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."

You really think that sentence was written by a person with a tenuous grasp of the English language. Seriously?

Re:Very limited scope (0)

Anonymous Coward | about 7 months ago | (#44912581)

I am confused, are we talking about the precedent sentence in quotes or are we discussing about the one in the TFA. Your ambiguity is really annoying and it feels amateurish.

Re:Very limited scope (1)

Zero__Kelvin (151819) | about 7 months ago | (#44912661)

That's funny. I was going to say the same thing about your inability to create an account and log in! (Also, there is zero ambiguity; I was in fact quite specific.)

Very limited indeed (4, Informative)

gentryx (759438) | about 7 months ago | (#44912601)

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.

Misleading title (0)

Anonymous Coward | about 7 months ago | (#44912339)

High performance Fortran compilers for supercomputers and clusters have been around since before a good portion of the posters here were born. In fact, they often beat compilers for other languages. In certain disciplines like atmospheric science, Fortran is the language for super computing problems, even today. Misleading title.

bigger problems (1)

stenvar (2789879) | about 7 months ago | (#44912345)

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 (1)

bored (40072) | about 7 months ago | (#44912603)

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 (1)

oursland (1898514) | about 7 months ago | (#44913225)

It's still true. Fortran uses these intrinsics as well, furthermore the way Fortran handles variables is stronger than C/C++, which permits the compiler to perform more aggressive optimizations. Fortran also has convenient syntax for performing common mathematical operations on datasets. Yes, you can replicate this in C++ with operator overloading, but Fortran puts this in at the core language permitting the compiler writers to target these specific operations for optimization.

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 (1)

stenvar (2789879) | about 7 months ago | (#44913355)

C++ is pretty much the only language that has BLAS libraries that can actually beat the fortran ones.

Why would any Fortran compiler be using a slower BLAS implementation than the C compiler?

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

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 (1)

gentryx (759438) | about 7 months ago | (#44912751)

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 (1)

emt377 (610337) | about 7 months ago | (#44913041)

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 (1)

stenvar (2789879) | about 7 months ago | (#44913383)

You never want a compiler to vectorize code.

I most certainly do.

Just like you don't want compilers to provide multidimensional arrays - memory isn't multidimensional, so there's no natural layout

There is a natural layout that handles 99% of all numerical needs. Numerical programmers understand it, and so do compilers.

NONE of this has a natural representation.

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 (1)

stenvar (2789879) | about 7 months ago | (#44913375)

We're using Boost Multi-array [boost.org] as a multi-dimensional array

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.

Regarding the speed issue: yeah, that's nonsense today [ieee.org].

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 (1)

gentryx (759438) | about 7 months ago | (#44913399)

Care to backup those claims with actual code/numbers? I'm just asking because my FUD alarm just rang. Part of my job is performance engineering. My experience is that if you use C++ correctly, you get code which at least matches Fortran code.

Re:bigger problems (1)

mjwalshe (1680392) | about 7 months ago | (#44912985)

If since 1979 a language hasn't manged to support things like multidimensional arrays maybe taking it out behind the back of the barn with a shotgun might be the best solution.

Re:bigger problems (0)

Anonymous Coward | about 7 months ago | (#44913457)

C++ doesn't lack multidimensional array types, you blithering idiot. They just aren't first-class objects.

Its code not codes FFS (1)

mjwalshe (1680392) | about 7 months ago | (#44912381)

And why would you fuck about with C++ when there is so much missing - just get a book and learn FORTRAN if you need to work in the scientific computing environment.

Re:Its code not codes FFS (0)

Anonymous Coward | about 7 months ago | (#44912429)

When dealing with many HPC centres, the word 'code' is used instead of 'program' or 'application'. So 'codes' is correct, it simply means that two or more programs are involved.

Re:Its code not codes FFS (1)

Greyfox (87712) | about 7 months ago | (#44912729)

If I were doing new development, which I am, I would use C++ because like Java and Ruby I can develop code in it more quickly, make my libraries more user-friendly (Where the user in this case is another programmer or myself later on) and am more likely to be able to find other programmers who can use those libraries without requiring them to learn an ancient language that just barely qualifies as structured-programming-capable. And yes, I HAVE written fortran code. And assembly, back in the day.

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 (2)

oursland (1898514) | about 7 months ago | (#44913289)

Then you're likely a waste of time and detriment to your team.

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 (0)

Anonymous Coward | about 7 months ago | (#44913485)

You have no idea what the fuck you are talking about. Either your "friends" doesn't exist or they are full of shit.

Re:Its code not codes FFS (0)

Anonymous Coward | about 7 months ago | (#44913663)

You are c++ villiage idiot!

Re:Its code not codes FFS (2)

jythie (914043) | about 7 months ago | (#44913695)

Not really. When projects are already dominated by a particular language, esp projects that can have decades or more of legacy design to them, programmers who want to come in and rewrite perfectly good subsystems in their preferred language are not all that well looked upon.

Re:Its code not codes FFS (1)

jythie (914043) | about 7 months ago | (#44913683)

Many technological decisions are based off how easy it is to find programmers to fill roles, which means if you want to be able to easily hire people onto a project you have to bend to what is generally popular. I worked on several projects that ended up switching languages or even OSes because what we were using made finding candidates more difficult.

Modern Fortran (0)

Anonymous Coward | about 7 months ago | (#44912385)

Modern supercomputers all have perfectly adequate Fortran compilers from a variety of vendors, so I'm not sure what problem this library is trying to solve.

And yes, in HPC-world an application is known as 'a code'. Believe it or not the ones I work with have configuration files known as 'input decks', a terminology dating back to the days of punch card input.

Re:Modern Fortran (2)

rubycodez (864176) | about 7 months ago | (#44912521)

more than adequate, Fortran is still the most optimizable language for high performance numeric computation, moreso than C and derived languages

Re:Modern Fortran (1)

dfghjk (711126) | about 7 months ago | (#44912793)

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 (1)

oursland (1898514) | about 7 months ago | (#44913247)

Compilers often cannot make optimizations in C/C++ and similar languages because of how flexible the languages are to the user's needs. Fortran, on the other hand, is more restrictive and the compiler can make guarantees about aliasing and alignment that permit things like autovectorization. This really is a part of the core language, not just the result of monumental resources put at the issue.

Re:Modern Fortran (1)

gentryx (759438) | about 7 months ago | (#44912773)

Yeah, if your Fortran code already scales on big iron, then LibGeoDecomp probably doesn't have much to offer for you. This article was rather meant as a primer for those who are working on older, sequential Fortran codes which are not yet parallelized, and who don't want to go through all the pains of building an MPI-enabled parallelization for them.

Send In The Codes (0)

Anonymous Coward | about 7 months ago | (#44912453)

Isn't it rich?
Are we a pair?
Me here at last on the ground,
You in mid-air.
Send in the codes.

Isn't it bliss?
Don't you approve?
One who keeps tearing around,
One who can't move.
Where are the codes?
Send in the codes.

Just when I'd stopped
Opening doors,
Finally knowing
The one that I wanted was yours,
Making my entrance again
With my usual flair,
Sure of my lines,
No one is there.

Don't you love farce?
My fault, I fear.
I thought that you'd want what I want -
Sorry, my dear.
And where are the codes?
Quick, send in the codes.
Don't bother, they're here.

Isn't it rich?
Isn't it queer?
Losing my timing this late
In my career?
And where are the codes?
There ought to be codes.
Well, maybe next year . . .

Fortran works fine with MPI (5, Informative)

poodlediagram (1944244) | about 7 months ago | (#44912825)

...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.

Re:Fortran works fine with MPI (0)

Anonymous Coward | about 7 months ago | (#44912877)

And Fortran 2008 brings goodies not found anywhere else.

Re:Fortran works fine with MPI (1)

oursland (1898514) | about 7 months ago | (#44913237)

I'm not 100% sure on that. Languages like Go have brought in a lot of the same things, like language-level concurrency. However, Fortran has really been designed to address the problems that are solved on supercomputers first and general language second. This makes it far easier to focus on the task at hand instead of working around limitations in the language.

God... (1)

Anonymous Coward | about 7 months ago | (#44912849)

You do know that Fortran 2008 has better support for parallelism and concurrency than c++ don't you? Or do you still think everyone is using F77?

"Legacy" Fortran code? (1)

Anonymous Coward | about 7 months ago | (#44912895)

As long as you need a double C (and forget about C++) standard committee tracker diploma to write a fucking function processing three non-aliased arguments with two-dimensional runtime-sized arrays, a C compiler supporting the most recent standards will produce much worse code than a Fortran compiler compiling some 50-year old Fortran subroutines written by a reasonably good mathematician without much programming experience.

Of course, if we are talking about earlier C standards, not even a standard-following geek has a chance to come close. And if we are talking about C++, we are still waiting for standards that allow efficient code generation for the most basic numerical subroutines.

Try it: write a simplistic Fortran subroutine doing a matrix multiplication for variable-sized multidimensional arrays. Easy to write in a Fortran-IV subset of the language. A moderately talented squirrel could do it between focusing on its nuts.

Then try to coax a C or C++ compiler into generating anything closely efficient. You'll need to revert to recent language standards, and your generated code will still have a much worse product of runtime times incomprehensibility.

That's why extern "Fortran" is still the most important numeric C code ingredient. Because the old libraries were written by genius mathematicians and lousy programmers, and you need genius programmers to get the stuff close to good in C/C++. But double geniuses are hard to come by.

Efficient software is more than good assembly (1)

gentryx (759438) | about 7 months ago | (#44913045)

Your argument seems to focus mainly on how well a compiler can optimize a given code. But writing efficient software takes more. Ever tried to implement an AMR or 3D cache blocking in Fortran? It's a pain. Object orientation gives your programmers a huge boost in efficiency. And if they can use this efficiency to implement algorithms which converge faster, then this will make your code ultimately run faster. Even the last piece, the arithmetic kernel, can be done efficiently in C++ if you adopt modern libraries like Boost SIMD [meetingcpp.com].

You only have to rewrite it a *little* bit (4, Insightful)

msobkow (48369) | about 7 months ago | (#44912991)

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? (1)

gentryx (759438) | about 7 months ago | (#44913087)

Just asking because otherwise you'd had a better view on how intrusive (or not) this restructuring is. To give some numbers: a while ago we ported a simulation (video here [youtube.com]) to the library. The simulation model was about 5000 lines of code. Not much, but the code was highly condensed and had been carefully modeled in the course of 3 years. We ended up having to change less than 100 lines to make it work with LibGeoDecomp. That's a far cry from a rewrite.

wow, FORTRAN (-1)

Anonymous Coward | about 7 months ago | (#44913017)

i forgot all about The IBM Mathematical Formula Translating System. thanks for reminding me. i need to play with FORTRAN again. maybe I can find a free compiler for Windows 8 64 bit or at least a free emulator of some sort.

program hello
                    print *, "Hello World!"
end program hello

Targeted at Managers (1)

PPH (736903) | about 7 months ago | (#44913097)

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 (1)

spaceyhackerlady (462530) | about 7 months ago | (#44913103)

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 (4, Interesting)

excelsior_gr (969383) | about 7 months ago | (#44913137)

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... (2)

tlambert (566799) | about 7 months ago | (#44913193)

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".

But aside from that, Mrs. Lincoln? (1)

russotto (537200) | about 7 months ago | (#44913251)

Source code modification is required, but mostly limited to restructuring into a new pattern of subroutines.

That's not what I call "limited". More like a rewrite, or at least a salvage operation.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...