problems converting Fortran 77 code to Fortran 90
Author Message
problems converting Fortran 77 code to Fortran 90

Hi,

Forgetting there existed some utilities to convert "standard" fortran 77
code to Fortran 90 code, I made the conversion manually for a 500 line
subroutine.  Most of it was standard: switching ampersand locations,
changing comment characters (C -> !) converting continues to "end do" --
most if not all of which were easily accomplished with emacs
search-replace.  Once completed, I tested the code and found the results
magically different, not unreasonable, but wrong.

I thought well, maybe I made a mistake in my conversion, so I found
convert.f90 (ftp://ftp.numerical.rl.ac.uk/pub/MandR/convert.f90) and
applied it to the old Fortran 77 subroutine.  After testing this, I get
precisely (to double precision) the same result as my manual conversion.
This leads me to believe two possibilities:

1) the Fortran 77 code (not written by me) was getting by doing something
"wrong" and getting the "right" answers.

2) the "f90" code is having some problems with the subroutines it
references, all of which are still Fortran 77.

Why convert?  Here's a section of the Fortran 77 code and a
called subroutine:

C               Compute gamma plus
CALL MMULT (N,N,N, UPREFLECT(1,1,1), DOWNREFLECT(1,1,2), X)
CALL MIDENTITY (N, Y)
CALL MSUB (N,N, Y, X, Y)
CALL MINVERT (N, Y, X)
C               Calculate the internal downwelling (plus) radiance vector
CALL MMULT (N,N,1, DOWNTRANS(1,1,2), INBOTTOMRAD, V)
CALL MMULT (N,N,1, UPREFLECT(1,1,1), V, S)
CALL MMULT (N,N,1, UPTRANS(1,1,1), INTOPRAD, V)
CALL MADD (N, 1, V, S, S)
CALL MMULT (N,N,1, UPREFLECT(1,1,1), DOWNSOURCE(1,2), V)
CALL MADD (N, 1, V, S, S)
CALL MADD (N, 1, UPSOURCE(1,1), S, S)
CALL MMULT (N,N,1, X, S, DOWNRAD)
...

SUBROUTINE MMULT (N, M, L, MATRIX1, MATRIX2, MATRIX3)
INTEGER  N, M, L,  I, J, K
REAL*8   MATRIX1(N,M), MATRIX2(M,L), MATRIX3(N,L),   SUM

DO 200 I = 1, N
DO 200 J = 1, L
SUM = 0.0
DO 100 K = 1, M
SUM = SUM + MATRIX1(I,K)*MATRIX2(K,J)
100       CONTINUE
MATRIX3(I,J) = SUM
200     CONTINUE
RETURN
END

The original programmer felt the need to write his own matrix
multiplication, adding, inverting, etc. routines.  I want to replace these
with f90+ intrinsics (matmul, etc) to reduce computational time.

Ideas on where to look first to identify the computed differences?  I
suspected some common blocks might have been the problem, but it appears
not to be the case.  All REAL variables/arrays are REAL*8 in the Fortran
77 program, they stayed that way after the automatic conversion.

Files are at (note: I didn't write any of these):

-Ben

Tue, 10 Jul 2007 02:42:34 GMT
problems converting Fortran 77 code to Fortran 90

Quote:
> I want to replace these
> with f90+ intrinsics (matmul, etc) to reduce computational time.

> Ideas on where to look first to identify the computed differences?

Well, I didn't really bother to study this in detail (other work calls),
but you seem to be mixing up a lot of unrelated things, few of which
have anything to do with the stated objective.

One of the really fundamental principles of tracking down differences
caused by changes: only make one change at a time.

First, the compiler and system. it is unclear to me whether or not you
are talking about the same compiler or different compilers. If you are
already talking about the same compiler, then skip this part. If you are
talking different compilers, then the first thing to do is to run the
original code with the new compiler. F77 is a subset of f90 and thus all
f90 compilers will run all standard-conforming f77 code (with exceptions
for bugs and for things that are standard-conforming but nonportable).

If you want to make cosmetic changes, do those separately.  And check
that they were really cosmetic by making sure that nothing changed.
Things like changing to free source form and using do/enddo count as
cosmetic. Note that I'm not implying that they aren't good things to
change, just that they don't have much of anything to do with the rest
of the changes you mentioned.

Then make the computational changes in the code.

I won't address the question of whether any of this is likely to achieve
your stated goal of reducing computational time... except that I'll note
that it is not a given. Using f90 intrinsics isn't a magic bullet that
will automatically help computation time. Might help. Might hurt.

Again, all these comments are pretty cursory and not based on serious
study of the code. I just noticed you mentioning a lot of changes that
caused the differences.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Tue, 10 Jul 2007 03:09:45 GMT
problems converting Fortran 77 code to Fortran 90

Quote:

> Well, I didn't really bother to study this in detail (other work calls),
> but you seem to be mixing up a lot of unrelated things, few of which
> have anything to do with the stated objective.

True, stated objective is (mostly) independent of the question I was
asking. I did not make any *intentional* computational changes to the
code.

The issue I was facing was: after "converting" to a form in which intel
fortran compiler would compile it with a .f90 extension, I was getting
different results.  However, upon following your suggestion of one change
at a time, I find that indeed I must have inadvertently changed
"something", because the results are consistent now.  I made too many
assumptions -- a character flaw at best.

Quote:
> One of the really fundamental principles of tracking down differences
> caused by changes: only make one change at a time.
> I won't address the question of whether any of this is likely to achieve
> your stated goal of reducing computational time... except that I'll note
> that it is not a given. Using f90 intrinsics isn't a magic bullet that
> will automatically help computation time. Might help. Might hurt.

It should in this case:  8 million calls to the subroutine MMULT I gave in
the original post vs. 8 million calls to the MATMUL intrinsic.

Quote:
> Again, all these comments are pretty cursory and not based on serious
> study of the code. I just noticed you mentioning a lot of changes that
> caused the differences.

You must have experienced these kinds of "ambiguous" posts quite often.
I will try to be more "diligent" in my descriptions and approach in the
future.

On a completely unrelated note: I see that you work for NASA Dryden -- I'm
at Goddard now, and am enjoying working here thus far, However, they are
very strict about certain things, such as posting to newsgroups using NASA
computers (according to the regulations).  Does Dryden have similar rules?
I'm hesistant to post through google or something similar using my office
box, so I use my university account to do it...

Also, I saw that a "Richard Maine" at Dryden was once an astronaut
candidate, is that you?

-Ben

Tue, 10 Jul 2007 04:30:15 GMT
problems converting Fortran 77 code to Fortran 90

Quote:

>> I won't address the question of whether any of this is likely to achieve
>> your stated goal of reducing computational time... except that I'll note
>> that it is not a given. Using f90 intrinsics isn't a magic bullet that
>> will automatically help computation time. Might help. Might hurt.

> It should in this case:  8 million calls to the subroutine MMULT I gave in
> the original post vs. 8 million calls to the MATMUL intrinsic.

It depends. According to a trivial benchmark I made, MATMUL tends to
be very fast for small matrices (say, 3x3). The advantage of MATMUL
being an intrinsic is that a smart compiler might inline it for small
matrices, thus saving the overhead of a procedure call. OTOH, for
larger matrices beating an optimized BLAS is _very_ hard. For small
matrices, BLAS does have some overhead which probably is the reason
why MATMUL often beats it. While I didn't look at your MMULT, I
suspect that depending on matrix size either a decent MATMUL or BLAS
will outperform it.

Benchmark results and code can be found here:

http://gcc.gnu.org/ml/fortran/2004-11/msg00124.html

PS: I usually try very hard to avoid writing spaghetti code like in
the benchmark code. I just wanted to experiment with ordering the
tests differently to see if there were any significant cache effects,
and since it was basically a small throwaway piece of code I didn't
care to structure it in any way...

--
Janne Blomqvist

Tue, 10 Jul 2007 05:13:06 GMT
problems converting Fortran 77 code to Fortran 90
(snip)

Quote:
> It should in this case:  8 million calls to the subroutine MMULT I gave
> in the original post vs. 8 million calls to the MATMUL intrinsic.

The intrinsic may or may not be implemented as a subroutine
call.  Note also that your MMULT expects the three arrays to be
distinct, but the intrinsic doesn't require that.  In some cases
the intrinsic form might use a temporary array and then copy to
the destination.  If you make more complex expressions using the
matrix intrinsics you are more likely to require a temporary.

It really is hard to say which will be faster until you try it.
(And then only for that specific compiler, library, processor.)

-- glen

Tue, 10 Jul 2007 05:17:16 GMT
problems converting Fortran 77 code to Fortran 90

Quote:
> On a completely unrelated note: I see that you work for NASA Dryden -- I'm
> at Goddard now, and am enjoying working here thus far, However, they are
> very strict about certain things, such as posting to newsgroups using NASA
> computers (according to the regulations).  Does Dryden have similar rules?

Indeed. It comes under the very broad categories of (depending on
specifics) either personal use of government stuff or representing the
government officially. Most of those rules are government-wide, though
details of interpretation and implementation might vary. For the long
and accurate version, see your appropriate legal office. For the short
(relatively :-)) version of my personal interpretation of it ...

1. There are some limited circumstances under which you can use
government systems for personal things. Details elsewhere, but "don't"
is always safe. For comp.lang.fortran, it isn't hard at all for me to
argue that it is work-related by any of several arguments, all of which
my boss knows about and agrees with. So does the Dryden CIO, who
approved letting my connections to the commercial usenet server go
through our firewall after Dryden stopped running their own server. The
NASA inspector general once had to deal with some complaints about me
that a notorious net.kook once submitted purely to harass me; the IG
concluded that the complaints had no valid grounds and that my use of
government equipment was appropriate. I'd suggest not posting to
alt.sex.{*filter*}, though.  :-) (I once participated in getting someone
"escorted off site" for things related to that one - details are way off
topic).

2. You need to be quite careful that you never give the impression of
saying anything on behalf of NASA. That's a big no-no. It must be clear
that it is all your personal opinion. Posting from a non-NASA system and
on your own time won't get you off of that hook. I'm not required to put
a legal disclaimer at the bottom of every posting, and I usually
don't... unless there seems like even the least possibility that someone
might misread such an implication into what I wrote.

3. General rules of professional behavior. Don't do things that make you
look so much like a jerk that it reflects even indirectly on NASA.
Profanity is an obvious example, but far from the only one. This, of
course, is far broader than (and long predates) usenet. Its also
generally a good idea anyway. :-)

Most of this is broader than usenet. The same issues would apply if I
picked up my (government-owned) phone to talk to you about Fortran.
Usenet is public enough to make the issues take on more significance,
but they are still basically the same issues. Am I using that phone for
personal things? Am I claiming to represent NASA hen I talk on it? Am I
giving an unprofessional impression?

Quote:
> Also, I saw that a "Richard Maine" at Dryden was once an astronaut
> candidate, is that you?

Yep. From quite a few years ago. Made the finalist list (last cut before
selection), but not the actual selection.

P.S. This is all my personal opinion and not official legal advice.  :-)

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Tue, 10 Jul 2007 05:37:32 GMT
problems converting Fortran 77 code to Fortran 90

Quote:
> Benchmark results and code can be found here:

> http://gcc.gnu.org/ml/fortran/2004-11/msg00124.html

Interesting.  Most of my arrays are 15x15 or so, sometimes larger.

Thanks for reminding me about BLAS, it's probably a good time to check it
out.  Am I correct in my recollection that BLAS is part of LAPACK?

-Ben

Tue, 10 Jul 2007 05:20:15 GMT
problems converting Fortran 77 code to Fortran 90

Quote:

>Am I correct in my recollection that BLAS is part of LAPACK?

Lapack uses the BLAS and provides a "reference implementation", but one
is supposed to use a hardware-specific BLAS to get optimal performance.
There is a "high performance BLAS" at
http://www.cs.utexas.edu/users/kgoto/signup_first.html . The Intel Math
Kernel Library at http://www.intel.com/software/products/mkl/ contains
a BLAS implementation. Several Fortran compiler vendors distribute a
compiled (and I assume optimized) Lapack library with their compiler .

Quoting http://www.netlib.org/lapack/ :

"LAPACK routines are written so that as much as possible of the
computation is performed by calls to the Basic Linear Algebra
Subprograms (BLAS). While LINPACK and EISPACK are based on the vector
operation kernels of the Level 1 BLAS, LAPACK was designed at the
outset to exploit the Level 3 BLAS -- a set of specifications for
Fortran subprograms that do various types of matrix multiplication and
the solution of triangular systems with multiple right-hand sides.
Because of the coarse granularity of the Level 3 BLAS operations, their
use promotes high efficiency on many high-performance computers,
particularly if specially coded implementations are provided by the
manufacturer.

Highly efficient machine-specific implementations of the BLAS are
available for many modern high-performance computers. For details of
known vendor- or ISV-provided BLAS, consult the BLAS FAQ.
optimized BLAS library for the architecture. A Fortran77 reference
implementation of the BLAS in available from netlib; however, its use
is discouraged as it will not perform as well as a specially tuned
implementation."

Tue, 10 Jul 2007 06:19:57 GMT

 Page 1 of 1 [ 8 post ]

Relevant Pages