Fortran vs. C for numerical work 
Author Message
 Fortran vs. C for numerical work


Quote:

>      While I'm at it, I sincerely hope that some cleaner language like
> Turing wipes C off the face of this planet.  I've about had it with all
> this "my language is better than yours" garbage from the C folk and can
> wish nothing for them other than extinction.

>                            Marc R. Roussel


 I inadvertently touched off one of these fortran-vs-C wars about 2 years ago
so let me apologize now for that one.  I have learned a bit since then, so I
offer my current perspective:

 (1) C is a lousy language for numerical work.
 (2) FORTRAN is a lousy language for anything BUT numerical work.
 (3) Both C and FORTRAN are lousy in that they facilitate writting highly
     bebugged code.

 I think that the main reason for such acrimonious debate is that neither side
is qualified to express meaningful opinions, because both sides are lacking
essential experience.  In particular:

 (1) FORTRAN programmers mostly do not know how to do "data structure"
     programming and recursion, so they do not know what they are missing;
 (2) C programmers mostly work on micros, workstations, or minicomputers,
     so they are not acquainted with pipelining, vectorizing, parallel
     processing, etc., so they do not know what they are missing by using C.

So what is one to do?

I see at least two solutions:

 (1) Stop doing numerical work [ :-) ]
 (2) Find or develop a language suitable for this sort of work.

 Perhaps most practicioners would prefer solution (2) ???
I like your suggestion of Turing.  Have you looked at Eiffel?  I am also
investigating Occam.  Any opinions on this?
--
Bill Hutchison, DP Consultant   rutgers!cbmvax!burdvax!ubbpc!wgh (work)
Unisys UNIX Portation Center    uunet!eidolon!wgh (home)
P.O. Box 500, M.S. B121         "At the moment I feel more like arguing than
Blue Bell, PA 19424             being good" Raymond Smullyan _The Tao is Silent_



Fri, 21 May 1993 23:34:50 GMT  
 Fortran vs. C for numerical work
Ouch!!!!! Another satisfied customer!

--
John L. Bradberry        |Georgia Tech Research Inst|uucp:..!prism!gt4512c


Marietta, Ga. 30067      |404 438-4181 (SCI)        |'...is this thing on..?'  



Sat, 22 May 1993 05:24:30 GMT  
 Fortran vs. C for numerical work

William> I see at least two solutions:

William>  (1) Stop doing numerical work [ :-) ]
William>  (2) Find or develop a language suitable for this sort of work.

William>  Perhaps most practicioners would prefer solution (2) ???  I
William> like your suggestion of Turing.  Have you looked at Eiffel?
William> I am also investigating Occam.  Any opinions on this?  --

I have looked a bit at Turing and Turing-Plus.  They are very nicely
designed languages, but do not have the constructs for the kinds of
abstraction that I would like.  For example, they have neither
operator overloading nor class/object features.  They *do* have a very
clean design that helps one program with fewer errors, but the style
of programming is much the same as with the traditional
Fortran/C/Pascal.

My interests right now are leaning more toward Modula-3, because of
its support for classes/objects.  I am still trying to install it on
my IBM RS/6000 where its tendency to promote everything to double
precision actually causes codes to run faster instead of slower!  I
have also not found enough tutorial/reference information to enable me
to get a really good feel for how to go about using Modula-3
effectively.  I suppose that practice is the only teacher available
for the moment....

C++ is, of course, another possibility, but so far I have not seen any
C++ code that looks any easier to read or understand than the
equivalent C code -- though my lack of experience might be the
important factor here.
--


College of Marine Studies, U. Del.      J.MCCALPIN/OMNET



Sat, 22 May 1993 01:39:11 GMT  
 Fortran vs. C for numerical work

Quote:

>> I see at least two solutions:
>>  (1) Stop doing numerical work [ :-) ]
>>  (2) Find or develop a language suitable for this sort of work.
>...
>My interests right now are leaning more toward Modula-3, because of
>its support for classes/objects.

Unfortunately, Modula-3 fails in the same way that C does with respect
to (pulling out a quote that you didn't quote):

Quote:
>> (2) C programmers mostly work on micros, workstations, or minicomputers,
>>     so they are not acquainted with pipelining, vectorizing, parallel
>>     processing, etc., so they do not know what they are missing by using C.

These optimizations apply about equally well (poorly) to C and
Modula-3.  The reason, barring whole-program optimization (interesting
in a land of pointers-to-procedures, too) is that Fortran has its
weird little parameters-are-not-aliased rule, and C and Modula-3 do
not.  It's a little easier to mandate not-aliased in a language
without recursive data structures (i.e., pointers) like Fortran; in
C/Modula-3/others, such a rule seems oddly stunted and special-case.

For example, consider "f(LIST p, LIST q), p notalias q".
Speaking Fortran, that means that the heads of the lists are not
aliased, but who knows about the rest?  One might, perhaps, say
something along the lines of either

  p(.cdr)* notalias q(.cdr)*  (default is aliased)
or
  p(.cdr)* mayalias q(.cdr)* (default is not-aliased)

to specify that the heads and the spines of the lists are not / may be
aliased.  (and what do I mean by not aliased?  For each run-time call,
taking the instersection of the two sets p(.cdr)* and q(.cdr)* should
yield the empty set, and mangle what I said to turn it into sets of
pointers to things.)

Anyhow, perhaps this explains why these rules have not been adopted in
other languages (yet).  All the solutions I come up with in a couple
of minutes appear weird, ad hoc, and non-general.  Non-aliasing
mandates have good effect on remote implementations of things (RPC),
too, which is another reason to like them even if you hate heavy-duty
optimizations.

I'd have to go read more about this stuff to get a handle on what is
good, bad, and ugly -- unless the FX-87 people want to get into a
discussion about their work (much of which remains unread by me,
unfortunately).  It helps to keep the constraints of checking and
inference in mind, also -- closure properties of regular languages
are very useful, for instance.

David



Sat, 22 May 1993 02:48:25 GMT  
 Fortran vs. C for numerical work

Quote:
>  (2) C programmers mostly work on micros, workstations, or minicomputers,
>      so they are not acquainted with pipelining, vectorizing, parallel
>      processing, etc., so they do not know what they are missing by using C.

You may be right, but I doubt your generalizations apply to *numerical*
programmers who happen to use C. I'd certainly feel quite restricted
without the network facilities I use (from C) to handle large-scale
parallel processing. And I regularly use a minisuper and a supermini
with state-of-the art vectorizing and pipelining respectively.

Quote:
>  (1) Stop doing numerical work [ :-) ]
>  (2) Find or develop a language suitable for this sort of work.
>  Perhaps most practicioners would prefer solution (2) ???
> I like your suggestion of Turing.  Have you looked at Eiffel?  I am also
> investigating Occam.  Any opinions on this?

I've found C good enough. Why should I switch?

---Dan



Sat, 22 May 1993 12:38:57 GMT  
 Fortran vs. C for numerical work

Quote:

> >               [ critical remarks about C programmers deleted ]
> [ ... ] And I regularly use a minisuper and a supermini
> with state-of-the art vectorizing and pipelining respectively.

 I do not have a chance to work with this class of machine, so maybe you can
help me.  It is my impression that FORTRAN can do automatic vectorizing more
easily than C because the FORTRAN loop and flow of control statements are so
restricted (that surmise seems to be supported by other postings in this group).
In C, on the other hand, my impression is that the programmer must do his/her
vectorizing "by hand"; that compilers cannot do as much of the work
automatically.  If I am wrong on this point I would like to be corrected.

 Would you please post a page or so of a representative sample of your
vectorized C so we can look at the coding techniques?  Thanks!

Quote:
> I've found C good enough. Why should I switch?

         If you can handle it, go for it!

Quote:
> ---Dan

  Bill
--
Bill Hutchison, DP Consultant   rutgers!cbmvax!burdvax!ubbpc!wgh (work)
Unisys UNIX Portation Center    uunet!eidolon!wgh (home)
P.O. Box 500, M.S. B121         "At the moment I feel more like arguing than
Blue Bell, PA 19424             being good" Raymond Smullyan _The Tao is Silent_


Sat, 22 May 1993 22:22:51 GMT  
 Fortran vs. C for numerical work


|> >> I see at least two solutions:
|> >>  (1) Stop doing numerical work [ :-) ]
|> >>  (2) Find or develop a language suitable for this sort of work.
|> >...
|> >My interests right now are leaning more toward Modula-3, because of
|> >its support for classes/objects.
|>
|> Unfortunately, Modula-3 fails in the same way that C does with respect
|> to (pulling out a quote that you didn't quote):
|>
|> >> (2) C programmers mostly work on micros, workstations, or minicomputers,
|> >>     so they are not acquainted with pipelining, vectorizing, parallel
|> >>     processing, etc., so they do not know what they are missing by using C.
|>
|> These optimizations apply about equally well (poorly) to C and
|> Modula-3.  The reason, barring whole-program optimization (interesting
|> in a land of pointers-to-procedures, too) is that Fortran has its
|> weird little parameters-are-not-aliased rule, and C and Modula-3 do
|> not.  It's a little easier to mandate not-aliased in a language
|> without recursive data structures (i.e., pointers) like Fortran; in
|> C/Modula-3/others, such a rule seems oddly stunted and special-case.
|>
|> [example of passing two lists]

I agree with your observation that Modula-3 can yield the same aliasing
problems as C, and with your additional point that it is not enough
to declare that the top level objects are not aliased.  

However, I disagree with the implication that having recursive data
structures implies having pointers.  Hermes has recursive data structures
but does not have pointers.  Variable sized collections of things
can be declared as "table of <type>" or as "ordered table of <type>".
Additionally, a type (typically a table or a variant) may contain components of
the same type.  (For example type "S-expression" may contain a variant case
type "pair" whose components are of type "S-expression".)

From the programmer's point of view, every variable holds a separate
copy of the data and there is no aliasing.  However, the compiler and runtime
environment are free to optimize the performance of operations which copy or compare
"large" objects by letting equal data objects share storage.  So there
may be aliasing going on "under the covers" which the user doesn't see.
However, in these cases the compiler also takes the responsibility to ensure that
a true copy is made before any attempt is made to modify a shared copy.
This is the language-level analogue of "copy-on-write".
The "optimization" is beneficial only if the savings in copying/comparing
outweigh the costs of any run-time checks for aliasing.

|> Anyhow, perhaps this explains why these rules have not been adopted in
|> other languages (yet).  All the solutions I come up with in a couple
|> of minutes appear weird, ad hoc, and non-general.  Non-aliasing
|> mandates have good effect on remote implementations of things (RPC),
|> too, which is another reason to like them even if you hate heavy-duty
|> optimizations.
|>

I agree that if pointers are explicit, the problem is harder because
the programmer is generating the aliasing, but the compiler has to detect it
(or provide a way for the programmer to indicate potential aliasing).
This is harder then either the case where the programmer is responsible
for both generation and detection or the case where the compiler is
responsible for both.

|> I'd have to go read more about this stuff to get a handle on what is
|> good, bad, and ugly -- unless the FX-87 people want to get into a
|> discussion about their work (much of which remains unread by me,
|> unfortunately).  It helps to keep the constraints of checking and
|> inference in mind, also -- closure properties of regular languages
|> are very useful, for instance.
|>
|> David

--

IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10958



Mon, 24 May 1993 03:22:00 GMT  
 Fortran vs. C for numerical work

  [ vectorizing in Fortran versus C ]

Quote:
> In C, on the other hand, my impression is that the programmer must do his/her
> vectorizing "by hand"; that compilers cannot do as much of the work
> automatically.

The Convex compiler easily recognizes all the standard loop idioms. With
-va it treats all formal array parameters as unaliased; I've never had
to use any directives other than this.

Quote:
>  Would you please post a page or so of a representative sample of your
> vectorized C so we can look at the coding techniques?  Thanks!

There's nothing really special... Here's a slightly interesting example.
The compiler knows that x and y are unaliased. neg() is a vectorizable
operation.

#ifdef VECTOR
   for (i =     0; i <  k; i++) y[i] = neg(x[i + r - k]);
   for (i =     k; i <  r; i++) y[i] = x[i - k];
   for (i =     0; i <  r; i++) x[i] = y[i];
#else
   for (i =     0; i <  k; i++) y[i] = x[i + r - k];
   for (i = r - 1; i >= k; i--) x[i] = x[i - k];
   for (i =     0; i <  k; i++) x[i] = neg(y[i]);
#endif

In this ANSIfied age I should set up a third version, like the second
but based on memmove(); but I doubt that'll be faster than the first on
most vector machines.

---Dan



Sun, 23 May 1993 06:52:48 GMT  
 Fortran vs. C for numerical work

Quote:


> :-( Flame on the fortran flame wars :-(
> first he tries to tell fortran programmers to convert to C (r
> "read the output of f2c for 5 minutes a day" then says...

No, I didn't. I pointed out that a Fortran programmer who wanted to
learn C the easy way could take advantage of f2c. Notice the adjective
phrase beginning ``who.''

First Jim ignores ``packed'' in ``packed array trie.'' Then someone else
ignores ``like C'' in ``Fortran does not have separate compilation like
C.'' Then a dozen people ignore ``per byte'' and ``for sorting numbers''
in the sorting discussion. Now Greg can't read ``who wants to learn C''
after ``Fortran programmer.'' I know Mark Twain didn't think much of
adjectives, but this is getting a little ridiculous.

---Dan



Tue, 25 May 1993 02:34:34 GMT  
 Fortran vs. C for numerical work

:-( Flame on the fortran flame wars :-(

first he tries to tell fortran programmers to convert to C (r
"read the output of f2c for 5 minutes a day" then says...

Quote:

>I've found C good enough. Why should I switch?

>---Dan

The fortran programmer is asking the same question.

*** sigh ***

Always use the tool most suitable for the job.

Replies to alt.flame.

--
Greg Franks, (613) 788-5726               | "The reason that God was able to    
Systems Engineering, Carleton University, | create the world in seven days is  
Ottawa, Ontario, Canada  K1S 5B6.         | that he didn't have to worry about



Mon, 24 May 1993 22:49:50 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Fortran vs. C for numerical work

2. Fortran vs. C for numerical work

3. C vs Fortran for numerical work

4. Fortran vs. C for numerical work

5. C vs Fortran for numerical work

6. Fortran vs. C for numerical work

7. Re : Fortran vs. C for numerical work

8. C++/FORTRAN for numerical work

9. Fortran vc. C for numerical work

10. Languages for Numerical Computation --- Was C vs FORTRAN

11. Different Numerical answers: VMS vs. Unix Fortran

12. Fortran vs C for numerical computation

 

 
Powered by phpBB® Forum Software