[Beowulf] Quick question... on Fortran

[Robert G. Brown]

On Sat, 14 Apr 2007, Brian Dobbins wrote:

>> From one Fortran averse person to another:
>
> Using the PGI compilers (at least as of 6.0, but 7.0 is out now and does
> the same), you can allocate at -least- up to 32GB in an array with Fortran
> on 64-bit systems.  I say at least because I don't currently have more
> than 32GB on any of my nodes.  :)
>
> The way to do this is to use the 'mcmodel=medium' option and to promote
> integers to 8-byte values (for indexing the entries in this array) with
> '-i8'.
>
> (For example: 'pgf90 -mcmodel=medium -i8 test.f90 -o test.exe')
>
> Of course, if you want to try this yourself, Robert, I'm happy to let you
> log in and give it a shot for the sole pleasure of seeing you touch
> Fortran code.  ;)

Hah.  I still have several megabytes worth of fortran source code that I
typed into a computer one byte at a time over a decade and a half.  I
also have a couple of books, e.g. Forsythe, Malcolm and Moler, with
lovely numerical code in fortran written into them.  I've even gone in
and tediously, carefully, ported that code to C so I could still use it.

Now I just use the GSL.  I honestly wonder how much fortran legacy is
maintained just because nobody wants to rewrite numerical code -- but
either way the GSL is better than whatever it was that some grad student
wrote, way back when, in nearly all cases.  Just a glance at cernlib
convinced me that whole chunks of cernlib could go away, for example, if
anybody ever sat down and slogged through the port.

Of course at this point I have WAY more C source than I ever did
fortran.  Maybe as much as 8-10 MB.  That's quite a lot, one character
at a time, even if it does include e.g. comments.

However, I fully recognize a) that fortran can be a lot easier for
compilers to optimize than C, because it is hard to optimize the
arbitrary manipulations of pointers that C permits.  If you use C and
pointers, you code closer to the assembly language bone and can do
amazing things, but you're also responsible for more of the work of
optimization.  Also b) legacy or not, alternatives or not, choosing to
port or not port a large existing code base from fortran to C is not
cheap.  Been there, done that, one more than one occasion.  It requires
a major commitment of resources, time and energy.  Once you're DONE
there are benefits as well -- significant ones in my opinion.  However,
as time passes even those benefits are diminishing as fortran becomes
more C-like.

One of the interesting things about computer languages is that they
really are dynamic, if somewhat slowly varying (decadal time scale, not
annual timescale).  The fortran you code in is not (probably not,
anyway) the Fortran IV I learned back in the 70's and coded in
extensively until the mid to latter 80's.  The F77 Steffen is talking
about expanding isn't the f90, f95, f2003 that gfortran is moving
towards.  The C I learned back in the mid-80's (DeSmet C on an IBM PC:-)
isn't the Unix K&R C I learned a bit later, or the ANSI C I had to port
to after that, or the C99 that gcc is sort-of compliant with.  In fact,
gcc is almost a variant all its own.

Who knows, in ten years we may see a merge of fortran and c into a
"supercompiler" that permits near transparent switching of syntax, or
inlining of fortran in c the way assembler can be inlined now.  It could
happen.  After all, there is no limit to how smart one can make a
compiler, and the components are all really there already in
g-compilers.  That might permit a genetic mixing of the two and
emergence of a new "Cortran" or "fortraC" compiler that adds a binary
exponentiation operator to C, maybe some stronger typing, maybe a
cappucino machine.

Just kidding about the cappucino machine.

    rgb

>
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu