NOT Educating FORTRAN programmers to use C

[Tom Stockfisch]

In article <14186 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:
>From article <646 at chem.ucsd.EDU>, by tps at chem.ucsd.edu (Tom Stockfisch):

>....  C is inherently slower because extensive pointer use
>inhibits optimizations.  The optimizations most affected are pipelining
>and vectorization (so now you see why Fortran still beats C on the Cray).
>most C compilers don't even bother trying certain optimizations because
>the compiler writer felt the time would be wasted since the presence
>of pointers would usually inhibit the optimization anyway.

In the absence of vectorization, I don't think pointer aliasing is a
significant hindrance to optimization.  With vectorization, you
need some sort of "noalias" pragma.  There are, after all,
vectorizing compilers for the Cray and other vector machines.

>Note: one other small point - at least in principle, Fortran should
>be faster at character manipulation than C.

You write character manipulation programs in Fortran?

>The only built-in string feature
>in the C language is the string constant - which uses the less efficient
>null termination method for string lengths.

The standard allows str*() to be built-in.

>Aside from the above two issues Fortran and C are identical with
>respect to optimization.

I have worked on a machine that has a double-word fetch instruction.  It
works only on double-word boundaries.  Fortran cannot make use of it
because the 77 standard allows any two consecutive members of
a real array to be equivalenced as a double precsion array.  Double
precision memory fetches with fortran then require two fetch instructions,
taking almost twice as long.  The problem is compounded by the fact that
the machine has dual processors which must share a single memory bus.
A reasonable C implementation on this machine would simply require
type "double" to be aligned on 8 byte boundary.

>> And misspelled variable references result in definitions of new variables
>> initiallized to zero.

[Someone pointed out my partial error here, the new variable is not 
guaranteed to start off zero]

>Yes, and the same sort of errors (a slip of the finger while typing) can
>cause serious problems in C as well.

I have never found a C typo as insidious.  If you type "+" for "=" it
should be obvious when you proofread.  There is also a decent chance
you'll get a syntax error.  When you type "leng" instead
of "len" in Fortran, you may forget exactly how you abbreviated
"length" and stare at it for hours without seeing what's wrong.
What's more, it is guaranteed that you *won't* get a syntax error.

>Besides, most Fortran compilers
>now have an IMPLICIT NONE statement

Given that it is Not Portable, I won't use it.

>(we are still lobbying X3J3 to require IMPLICIT NONE
>in Fortran 8x).

Good for you.

>As for loops without labels, Fortran 8x _will_ have a complete complement
>of label-less flow control constructs.  I doubt that any future C will
>have pointerless array manipulation though (that's one of the differences
>between the two languages - one is striving to improve, the other thinks
>it's already perfect).

I think it is only fair to compare Fortran 8x to C++, not C.

>Poor Fortran programmers tend
>to use GOTO too liberally and in inappropriate ways.  Poor C programmers
>tend to do the same thing with pointers (the GOTO of data structuring).

"Address Of" considered harmful?

>> Also, this ignores the importance of memory complexity, where malloc()
>> helps out enormously.  [...]

>I don't see how malloc helps in complexity.  Dynamic memory is _always_
>more complex than static memory.  The only way dynamic memory is useful
>is for objects whose size _can't_ be known at compile time or for large
>items which aren't in use simultaneously (and you want to keep your 
>program size small.  Either way, you code becomes _more_ complex when
>you use dynamic memory.

I was talking about complexity theory "complexity".  Fortran programs
must be compiled to use the maximum amount of memory someone might
ever want, or be faced with requiring the source to be re-edited
and re-compiled.  This wastes memory.  As I pointed out, wasting
memory can waste a lot of time if swapping occurs.

>Besides, malloc isn't part of C - it's part of the support library.

It's officially part of standard C.  It has been de facto part of
pre-standard C.

>If your Fortran has access to a LOC function (I have written LOC
>functions for systems that _didn't_ have it), and if you can turn
>off array bounds checking, then Fortran can even use malloc!

Highly unportable.

>C still has the problem that malloc() returns a pointer to the new
>space and that any code using the dynamically allocated space has its
>optimizations inhibited by that.  The Fortran 8x proposal has allocatable
>arrays which _aren't_ associated with pointers.  This will permit the
>code to be optimized just as if static arrays _only_ were used.

I don't see why a noalias pragma can't fix that.

>>>Fortran does some things real nice (try passing a variable dimensioned 3-d
>>>array into a C function - UGH!
>> void
>> doSomething( a, nlayer, nrow, ncol )
>> 	double	*a;
>> #		define A(i,j,k) a[ ((i)*nrow + (j))*ncol + (k) ]
>> {
>> 	...
>> 	A(1,2,3) =	...
>> 	...
>> }

>You're taking it on faith that your optimizer can do strength reduction
>and get those multiplies out of loops.

This is just an example that shows it isn't too painful to do.  I might
write the code differently if I thought the addressing scheme was
to slow.

>However, there _is_ a valid point to be raised here: you must define
>macros such as above for each array argument that gets passed and
>again in each other procedure that uses them.  Since this is extra
>work that isn't required in Fortran, there is a potential for error
>here that Fortran doesn't present.

Certainly on balance, C saves effort by being more expressive.  Adding
a few extra characters in a declaration does not seem to terrible to me.
It is more than offset by being able to say

	A( i+j, k-1, l/2 +7 ) +=	x

instead of

	A( i+j, k-1, l/2 +7 ) = A( i+j, k-1, l/2 +7 ) +	x

>For example: on my keyboard,
>plus '+' and equal '=' are on the same key - suppose I mistype
>the first plus in the macro as an equal?  The compiler won't catch
>it!

Yes it will.  "(i)*nrow" is not an lvalue.

>(I use this example because I've actually seen it done - it took
>several manhours to track down the problem.)

I don't understand why.  "+" doesn't look anything like "=".  If you
mistype an operator, I don't think you can reasonably expect the
compiler to catch it for you.  What if you type "+" for "-"?
The =/== typo is probably a better criticism, although lint usually
can catch it and people who work mostly with C tend not to do it.

>> As illustrated, fortran's variable-dimensioned array arguments can be
>> simulated in C with little effort.  Simulating dynamically allocated
>> arrays in Fortran is extremely difficult.
>
>Not at all!  The syntax compares one for one:
>
>    C                         Fortran
>
>   *p                         MEM(P)
>   *(p+i)                     MEM(P+I)
>   p=malloc(amount)           P=MALLOC(AMOUNT)
>   ...                        ...

What do you use for "[]"?

>Of course, the Fortran compiler is required to do some things that
>are automatic with C (like scaling the pointer arithmetic), but if
>the previous example was considered an adequate replacemment for
>Fortran arrays, then this should do nicely as a replacement for
>C's pointers.

Not at all.  The C macro is perfectly portable, the fortran MALLOC
is completely unportable.

>Actually, it makes a LOT more sense for a Fortran shop to wait for
>Fortran 8x than it does for them to switch to C.

How many years will they have to wait for Fortran 8x?
How many more years after that before stable compilers exist on
most machines?  From what I've heard, Fortran 8x might be,
like Ada, way too difficult to implement.

>I currently oppose the 8x proposal
>because it contains features which will severly cripple the language.
>Assuming they get rid of these though,

Is progress being made on revamping the proposal?

>I certainly would
>not recommend that working code in _either_ language be targeted
>for conversion into something new until such time a a language comes
>along which really _is_ better than these are.

Depends on the code.  I would probably leave most numerical Fortran
programs alone.  A compiler written in Fortran I would probably
translate to something else or rewrite from scratch.

>> [...]                          The "other language", in a few years
>> will probably be C++ (unless I'm being overly optimistic), which has
>> much more in common with C than F-whateve-comes-after-77 has in common
>> with F77.
>
>You don't sound optimistic to me.  C++ is not very good.  Objective C
>is marginally better....  Object Oriented programming
>features are welcome when they become muture

I think C++ is extremely useful right now.  Exception handling would
be very nice, but the Object Oriented stuff already available is fine.

>- preferably with a _much_
>cleaner implementation than C++ provides.

Fortran8x will have a cleaner implementation than C++?
-- 

|| Tom Stockfisch, UCSD Chemistry	tps at chem.ucsd.edu