Re: code speed moving from fortran 77 compiler to f2003 compiler

On 6/14/2010 11:02 AM, Lynn McGuire wrote:
Does anyone have experience with moving a large code set from
a f77 compiler (open watcom f77) to a modern day fortran 2003
compiler such as IVF ? I am interested in speeding up the code
execution. This is double precision floating point bound code
(from our testing in the past).

The code set is about 600,000 lines of f66 / f77 code. The code
set currently requires zero initialization and saving of all
local variables. There are about 10,000 lines of c and c++ code
interspersed throughout the f77 code. The f77 code is all
double precision and arrays are hand looped.

I have tried to port the code to IVF in the past but have run
into trouble with the zero initialization code in IVF.

The open watcom f77 compiler was the premier 32 bit compiler in
it's day but that day has long passed. No array optimizations,
no matrix specializations, etc. Automatic parallelisms would
be nice but I doubt that the current code would lend itself
easily to these.

Lynn McGuire

A code of the size that you have, especially if it is monolithic rather than modular, is going to involve a substantial amount of effort to convert from F77 to F2003 or F95, even if you use tools to do the bulk of the conversion. There is a definite possibility that the code, after conversion, will run slightly _slower_. Are you prepared for that?

On the other hand, if, as part of the conversion, you undertake to re-examine the underlying algorithms, and review the code for its being suited for a modern, large shared memory, multi-level cache and multiprocessor target architecture, you may obtain speed gains of one or more orders of magnitude.

Let me give you an example. There is a NASA Lewis combustion code, called CEA, which is in F77. One of the things it does is to read thermochemical properties from an unformatted file. However, every time it needs the property of one species, it rewinds and reads the file until it finds the record of interest. When the program was originally written, there would not have been enough memory ("core") to hold all the needed data for hundreds of species. Today, however, it is enough to read all the dat into memory in one slurp, just once. The resulting speed increase (new F95 version versus old F77 version) was tenfold.

Another example, from the same code conversion as in the previous paragraph. Some variables were used without initialization (or relied on incorrect zero initialization, which many old Fortran compilers provided as default). Fixing these bugs made the iterative solutions converge in fewer iterations.

There is a class of program bugs which tend not to draw enough attention to become candidates for fixing: bugs that slow the program down without affecting the correctness of results.

If your program uses, say, multivariable optimization, using a modern algorithm in place of one that was available in 1970, say, may well yield a ten- or hundred-fold speed up.

Another issue is maintainability. As they say, it is possible to write spaghetti-Basic in any programming language. The more complete interface and type checking, the INTENT feature for arguments, the new structured programming features will make your code more maintainable after conversion.

In summary, a mere conversion from F77 to F95/F2K is probably not justified if your code uses efficient algorithms that have been correctly implemented. Sorry, no silver bullet here.

-- mecej4

Relevant Pages

  • Re: Smaller C compiler
    ... > undefined behavior from printf. ... the 8-digit displayed values implies the compiler ... if the result of a conversion is wider than the field ... provided that I don't shift by more than 15 at a time. ...
  • Re: Fortran 77 comment lines
    ... is rare because comment lines in F90 are different than F77. ... You might be wondering what kind of compiler will be needed to ... is not standard f77, but it was a very widely adopted extension. ... f90 and later compilers tend to include ...
  • Re: F77 vs F90+
    ... And LOLD is not a logical variable variable by default, ... As noted above, IMPLICIT NONE does not ... no, my F77 is, as pointed out by Richard, ... not a complete F77 'spec compiler, but not extended beyond F77 scope ...
  • Re: writeObject signature
    ... > or the compiler must do a cast to Object. ... Java refers to a syntax for type conversion -- namely, ... it would be wrong (or bad design) to ...
  • Re: Is this expected behavior or not
    ... That does not explain why representation needs to be checked. ... the compiler should be free to choose. ... routine was inherited or called by a conversion of an operand). ... No model exist which would allow re-dispatch on scalar value. ...