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: (Score:3)
It really does lower one's opinion towards the author. If I read TFAs, I wouldn't read this one.
Re: (Score:3, Insightful)
Re: (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: (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 maintai
Re: (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
Re: (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
Re: (Score:2)
Re: (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: (Score:2)
I had some common taters for dinner.
Re: (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: (Score:2)
Re: (Score:2)
never worked in the field of high performance numerical methods?
Re: (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: (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: (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: (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
Re: (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: (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: (Score:3)
Re: (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: (Score:2)
"Secret codes" or "cipher codes" are countable. So are "weather simulation codes".
Re: (Score:2)
Re: (Score:2)
Re: (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 t
Re: (Score:2)
Re: (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: (Score:3)
Re: (Score:2)
In regard to:
You really think t
Re: (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: (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: (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: (Score:2)
Lots of existing code is
Re: (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 lang
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: (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)
Re: (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 i
Re: (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
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: (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 executa
Re: (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,
Re: (Score:2)
Its code not codes FFS (Score:2)
Re: (Score:2)
Unlike Ru
Re: (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 rewr
Re: (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
Re: (Score:3)
Re: (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 t
Re: (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: (Score:2)
Re: (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: (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: (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: (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: (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 s
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 eve
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
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 nitro
Re: (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
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: (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: (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: (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 Py
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: (Score:2)
Re: (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 th
Re: (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 essenti
Re: (Score:2)
Re: (Score:2)
Yes you can, since Fortran 2003.
Re: (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
Re: (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: (Score:2)
Re: (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: (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: (Score:3)
more than adequate, Fortran is still the most optimizable language for high performance numeric computation, moreso than C and derived languages
Re: (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: (Score:2)
Re: (Score:2)
Efficient software is more than good assembly (Score:2)