code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: Lynn McGuire on 14 Jun 2010 12:02 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. Sincerely, Lynn McGuire
From: dpb on 14 Jun 2010 12:26 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 ? ... Lynn, I'll make some of the same comments I've made in the OW forum... I have little doubt that generically speaking IVF is now more capable optimizing than was Watcom then but if your compute routines are still going to rely on the previously discussed usage of the home-rolled C malloc'ed dynamic memory it may not be of as much benefit might otherwise be. OTOH, if that memory allocation is at a higher level and you simply pass arrays and look within the subroutines that have those arrays as dummy arguments, then you may see some benefits of more modern optimization techniques as well as taking better advantage of current hardware capabilities. We've had the generic discussion multiple times in the past but I've never actually seen any of the code to look at specifically. I'd again reiterate that the only way you'll be able to know for sure will be to take some representative portions of the code that are able to be compiled and run w/ the two and compare the results empirically. --
From: mecej4 on 14 Jun 2010 13:57 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. > > Sincerely, > 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
From: Tim Prince on 14 Jun 2010 14:30 On 6/14/2010 9: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. > > 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. > > I have tried to port the code to IVF in the past but have run > into trouble with the zero initialization code in IVF. > Dependence on default SAVE syntax has been an obstacle to optimization for over 2 decades. This is why it was never part of the Fortran standard, and (from f77 on) better alternatives are offered. Default SAVE was a response to the widespread (but not universal) use of such an extension under f66. ifort does a reasonable job of emulating the default SAVE behavior of its predecessor, when the associated options are set, but that will make further optimizations difficult, as those options are incompatible with parallelization. At least on the C side, improved options are available for catching such dependencies. Since you bring up C++, most C++ programs written prior to the institution of C++ standards, or not checked for portability, are likely to require significant updating, regardless of your compiler choice. -- Tim Prince
From: glen herrmannsfeldt on 14 Jun 2010 14:57
Lynn McGuire <lmc(a)winsim.com> 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). Others have made some good suggestions, I will add a few different ones. > 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. Assuming the loops are in the right order, in most cases hand-looped code is at least as fast as array operations. Using array operations often uses temporary arrays, for example, where DO loops won't need them. Now, if you are running on a Cray vector processor, and the DO loops don't vectorize but array operations do, then maybe, but that is rare. There is one thing that lasted way too long in both Fortran and C, especially on windows machines, and that is allocating REAL*8 on odd four byte boundary. On the 80486, with a 32 bit data bus, that was fine, but it wasn't changed when the pentium came out, and the speed difference is fairly large. That doesn't require a new compiler, though. > 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. The "whole program" optimization of some of the newer compilers can speed up things considerably, especially inlining of functions that are fast but called many times. Also, inlining allows for some optimizations that otherwise aren't possible. -- glen |