Why we (still) need Fortran, and why this won’t change

I saw a link to an article from /. on Wodehouse’s ideas in writing prose used for refactoring code. For those not in the know, code refactoring is the process of rewriting a code to be simpler, or more efficient, more expressive of the needs.

What has this to do with Fortran, and in the bigger picture, HPC?

Everything.

Fortran has not been in vogue in CS departments in this century, nor for the latter portion of the past century. It is hard to find Fortran classes. C users decry Fortran as old technology. C++ sniff contemptuously at it.

But Fortran code exists, in massive amounts, in HPC and scientific and engineering computing circles.

Fortran itself has not stood still. It has evolved from being a difficult to replace tool of computing, to be a modern OO language, capable of doing the many things required of it for new code development. F2003 and beyond are not by any stretch the same languages that we may have learned and used in the 80s. But they will compile the codes written then.

And that is the critical aspect.

HPC codes developed twenty, thirty, and forty years ago can (and do) compile and run on modern systems. Critical research dependencies and computing pathways depend upon them. These codes represent huge sunk costs.

As the article points out, old and crusty code is battle scarred. It has withstood the tests of time. The rigors of use. Replace it with a modern C/C++ implementation, and you throw all that value away. And all the bug fixes. And corner case handling.

Which vastly increases the cost of the rewrite. It certainly increases the test cases one would have to write.

Think about this the next time an accelerator developer proposes having you rewrite your libraries and code base in their native C/C++ dialect to exploit their functionality. As many customers have told me recently, they would seriously consider accelerators, when they come with a decent fortran compiler. Until then, accelerators are not on the agenda. This was an eye opener to me personally, but I do understand it. And it represents a huge potential opportunity for the first group to do this. Since CUDA is based upon the Open64 compilers, my guess is that they will be first.

There is little doubt that accelerators are the future of HPC, there is no other way to get more efficient and larger numbers of instructions per unit time. Unfortunately, without lowering barriers, it would be very hard to enable existing users to make use of them. Demanding a user port their code, change their language, alter what they do to use your great new technology, is a non-starter in most cases. This is not a viable business model. Don’t believe me? Ask the customers. Tell them the value prop and the requirements.

Viewed 12932 times by 3136 viewers

Facebooktwittergoogle_plusredditpinterestlinkedinmail

2 thoughts on “Why we (still) need Fortran, and why this won’t change

  1. During my summer at Xilinx, I had a wonderful time figuring out how to get STSWM running from legacy Fortran to FPGA using F2C in the intermediate. F2C.h has a great definition for “barf” in the top comment lines (google “F2C.h”). F2C produces “good enough” C code for most existing blend of FPGA C compilers where “good enough” is the cost efficiency of 1 intern-summer / 10 kloc. This is likely the same for parallel programs on multicore and vector architectures: compiling legacy code is the easy part, partitioning and testing/profiling is the hard part.

    Especially for chaotic simulations like the shallow water simulation, comparing results of compiled code on two processors even from relatively low-level code can be a bit tricky. pne of the most difficult aspects of the development was the fact that Intel’s internal 80-bit Floating Point Unit registers only round/truncate to 64 bits when a variable assignment occurs in the code. Not only does this mean it is hard to verify FPGA results for complex simulations, but it also means that two chunks of code:

    a = (x + y)*z

    versus

    t1 = (x + y)
    a = z*t1

    can produce different results on the same x86 processor do to rounding/truncation.

  2. @Amir

    I have used f2c in various forms for the past ~16 years. It doesn’t really generate very good C, and the resulting code often doesn’t optimize well … which is sort of the point of accelerators. f2c is what you use when you don’t have a fortran compiler, and there is none on the horizon, and you have to get fortran going.

    That said, gfortran is a first class compiler in the gcc system, so there really is no excuse not to build it if you are using the gnu toolchain. If you aren’t using gcc, the Open64 compilers (SGI’s old compiler set, the basis of PathScale) could make a good foundation.

    On FP internals, yes, your comments are well understood. The 80 bit FP units are quite good, and preserve precision that 64 bit FP would lose. The problems we see (generally) are an inattention to the details of the calculation, in that you are not using real numbers.

    Floating point numbers are NOT real numbers, they have different properties. One of the simple examples I use to demonstrate this are two calculations that aren’t just mathematically equivalent, but in fact should be mathematically identical


    a+b == b+a

    If you follow the link, you will see what I mean.

    You have to know something of numerical analysis to understand error in calculations, as well as how the roundoff error accumulates, to really comprehend this.

    As some will note, it is a divergent series. Doesn’t matter, as we see the same thing with the Riemann Zeta function of order 2, which should converge nicely (and is a simple way to compute π)

    Optimization is mostly a reorganization of a calculation. If you change the order in which you perform FP operations, you will change the results. The question is whether or not one understand the results enough to discern good computations from bad …

Comments are closed.