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

From: Konrad Hinsen <[email-masked]>
Date: Fri, 22 Nov 96 10:53:11 +0100

> the structure of C programs.  This is so much so that I am having some
> difficulty grasping the overall structure of Fortran90 programs.  For
> 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

Remember that one of the criteria in the design of Fortran 90 was
compatibility with Fortran 77, which *is* archaic.

> 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-

A module defines a name space. Within a module, the only visible
names are those defined in the same module, or explicitly imported
from another module. That means you can have a function foo() in
several modules without name conflicts.

> ved with FORTRAN77?  What was deficient about this approach that
> prompted the introduction of "modules" in Fortran90?  Is there more to

Fortran 77 had no modularization at all. All names were global (plus
limited to six characters). This is one of the reasons for the weird
function names in many libraries (NAG is a good example). Using
the weirdest possible name was the best way to avoid name clashes.

In comparison to C, Fortran 77 is equivalent to K&R C without the
"static" qualifier.

> 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

Careful naming of variables (and functions) will lead to trouble
sooner or later.  As soon as you are working with many people on a big
project, or are using several libraries from external sources, you
will find it more and more difficult to keep up a consistent naming
scheme.  That's exactly the problem that C and C++ programmers have.

> Two areas that I am particularly concerned about are (1) managing the
> proliferation of versions of my source code; (2) high performance, in-

For version control, use RCS or something similar.

> cluding parallelization.  (Of course, neither of these topics is spe-

High performance is more a matter of compilers than of languages.
On most machines Fortran 77 outperforms both C and Fortran 90, but
that is largely (though not entirely) due to the long experience
with Fortran 77 code optimization for numerical applications.

As for parallelization, Fortran 90 doesn't care about it any more
than Fortran 77, C, C++, or any other "standard" languages. There
are languages which support automatic parallelization (e.g. Sisal
developed at LLNL), and several support libraries for other languages.

> geared for release, of my code.  My situation is that I am constantly
> making small changes to my not-for-release code, as part of my simula-
> tion "experiments," which means that I'm dealing with, effectively, a
> large number of versions, many of which differ very slightly from each
> other.  I keep notes on these changes (as comments on the code, or on

I had the same problem in the good old days - that is before I
switched to object-oriented programming. Now I have a huge collection
of more or less specialized modules containing "stable" classes.
Any general and/or finalized code goes in there, whereas any
experimental code stays in problem-specific "application" code
(which typically consists of a single very small file).

This is possible because OO programming allows me to add or replace
code in some class without touching the original definition. I just
write a short derived class that contains the new code. I wouldn't want
to go back to procedural-style development for any of my simulation
code!

BTW, my current preference of programming languages is a mixture of
Python and C. Python is a high-level interpreted object-oriented
language that allows quick code development and testing (see
http://www.python.org for more information). It also has a nice
interface to C (and languages that can be linked to C code, such
as Fortran on most machines), which I use to write the small
time-critical part of my code (e.g. energy evaluation). Plus it's
free and has been ported to any major operating system.

> 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?

All these questions are compiler-specific to some degree, and more
importantly they are rarely relevant. I doubt that the execution time
of any reasonably designed simulation code will ever be influenced
strongly by the cost of variable access or subroutine calls. I would
never compromise clean code structure for a minuscule gain in speed.

The generally recommended approach to program design an optimization
is

1) Design the basic structure for clarity and ease of modification.
2) Find the best algorithms for the key operations.
3) Write a first implementation without any special optimization.
4) Use a profiler to find performance bottlenecks (if any) and
   carefully optimize them. Typically this will affect only a
   very small part of the code.

Unfortunately many scientists are so obsessed with speed that they
completely forget about code design. The result is a large pool of
unreliable, incomprehensible, and user-unfriendly code, which has
probably caused some frustration for every CCL reader.

-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: [email-masked]
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------