Subject: Re: CCL:Q: Scientific Fortran for C programmers

From: [email-masked] (David Case)
Date: Thu, 21 Nov 1996 14:36:02 -0800

[email-masked] (Gabriel Berriz) wrote:
> 
> example, the whole business with "data blocks" seems bizarrely archaic
> to me.  But this is a minor issue.  More important is that I'm unclear
> on the usefulness of "modules."  How is a module different from a file
> with a whole bunch of subroutines in it?  How is modularization achie-
> ved with FORTRAN77?  What was deficient about this approach that
> prompted the introduction of "modules" in Fortran90?  Is there more to
> the rationale for modules than providing a finer control over variable
> scoping (which, I imagine, could be achieved with not much effort by a
> careful naming of variables)?  I am interested in reading discussions
> on the structure of (medium to large) Fortran programs, particularly
> ones geared to C programmers.

Data blocks are often like structures in C.  As I understand it, one of the 
principal driving forces in moving from Fortran77 to Fortran90 was to
allow much tigher checking of the consistency of how data is used in
different routines -- in the simplest cases, to type-check argument 
passing and other forms of inter-routine communication.  It's a little
like going from K&R to ANSI C.

>  ...requests ideas for version managament.....

I use RCS for just what you describe.  RCS does support branches, so you
can have a set of optimizations that go to a dead-end, then start over
from some previous point.  If you copy the RCS ID to the output files,
it's usually pretty easy to figure out which program gave which result.
And yes, I do try to save more or less every version, but disk space is
cheap, only the diffs are stored, and everything is in a single file.
Don't overlook using aliases to turn version numbers into more meaningful
version names.

But I hope you will post a summary of the better ideas people send to you.

> 
> As far as high-performance, I would like to learn about the effects of
> program structure on execution speed.  For example, how expensive, re-
> lative to their alternatives, are subroutine calls and modules in For-
> tran90?  Do COMMON variables slow down execution?  Does one get faster
> code if one avoids COMMON variables, and instead defines subroutines
> with a long list of arguments?

Just the opposite (usually): people use COMMONs to avoid long argument lists,
for speed considerations.  In fact, COMMON blocks can be quite efficient
if lack of memory is not a problem, since all of the address resolution is
done at compile time.

COMMON blocks are out of favor because it is difficult to impossible to
cross check them for consistency.  But carefully used, they can be a
very intuitive way of organizing and encapsulating some forms of data
structures.  Most F90 texts will show you how to construct roughly
equivalent ideas in Fortran90.

I assume you are familiar with comp.lang.fortran.  Lots of garbage goes
there, but also some very good threads, and you could start one yourself....

 ..dave case