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

A while back, someone posted a message about C vs fortran performance for
numerical work.  Unfortunately I missed all but the end of the thread.
Note: I don't wish to start a flame war here, but merely to provide facts.

As far as the aliasing problem is concerned in C, it can be overcome on
certain platforms much more easily than the lack of F90 compilers.  In
particular, Cray's cc is an excellent compiler, with lots of compiler
options that you can throw to better performance.  If you want to see
what's available, read the man page.  I will provide one excerpt since
it is relevant (from 'man cc' on Unicos 6.x):

                 restrict=f  Specifies that all function parameters that are
                             pointers to objects or incomplete types may be
                             treated as restricted pointers.  This means that
                             the compiler can assume that each such parameter
                             points to a unique array object; doing so
                             eliminates pointer parameters as sources of
                             potential aliasing.  You can use this option to
                             enhance vectorization and other optimizations.
                             You should not use this option if, during the
                             execution of a function, the value of an object
                             is modified and that object is referenced through
                             either of the following:  two different pointer
                             parameters; or a pointer parameter and a file
                             scope identifier.

When thrown, I get essentially exactly the same performance between C and
Fortran variants of a code (on a Cray) that passes arrays (pointers) to a
routine that does some significant operation on them in a loop.  Before
throwing it, the possible aliasing does indeed inhibit full vectorization.
The one danger here is that you are at risk of getting the wrong answer if
you ever do use aliasing, however, few scientific codes need to do that
(indeed it is technically illegal in Fortran) so this is a moot point.

To sum up, you can indeed get the same performance in C as in Fortran.  You
don't necessarily have to jump through hoops either.  It does depend on
support by the compiler of course, and is therefore site dependent.  I use
workstations and Crays, so for me C and Fortran are essentially equivalent in
speed.  In any case, this is something that can be easily checked on your
target platform, so it pays to be skeptical of blanket statements like
"fortran is faster than C" (I've actually seen some cases where it has been
slower).

--

Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]



Thu, 18 May 1995 16:14:39 GMT  
 C vs Fortran for numerical work

   To sum up, you can indeed get the same performance in C as in Fortran.
   You don't necessarily have to jump through hoops either.  It does depend
   on support by the compiler of course, and is therefore site dependent.  I
   use workstations and Crays, so for me C and Fortran are essentially
   equivalent in speed.  In any case, this is something that can be easily
   checked on your target platform, so it pays to be skeptical of blanket
   statements like "fortran is faster than C" (I've actually seen some cases
   where it has been slower).

One person pointed out that the workstations he uses do not have compiler
options to disregard the effects of aliasing.  Indeed, on my HP the worst
case scenario with full optimization runs about 1.8 times slower in C
than in fortran.  

However, my original point still stands.  CRI has proven that you can make C
or C++ numerical code as fast as fortran code, without difficulty, and on a
complex architecture to boot.  I would hope that workstation compiler vendors
are not that far behind (and user complaints would certainly help, hint
hint).

--

Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]



Fri, 19 May 1995 02:21:44 GMT  
 C vs Fortran for numerical work


   However, my original point still stands.  CRI has proven that you can make C
   or C++ numerical code as fast as fortran code, without difficulty, and on a
   complex architecture to boot.  I would hope that workstation compiler vendors

When such compiler flags are employed, the language being compiled is
no longer C. That is to say, codes written to conform with the
Standard no longer produce the results specified in the standard.
--
----------------------------------------------------------------

SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992



Fri, 19 May 1995 23:51:13 GMT  
 C vs Fortran for numerical work

|> [...]
|> As far as the aliasing problem is concerned in C, it can be overcome on
|> certain platforms much more easily than the lack of F90 compilers.  In
|> particular, Cray's cc is an excellent compiler, with lots of compiler
|> options that you can throw to better performance.  [...]

Yes, some implementations of C have extensions available which
overcome the speed deficiencies of the language.  These are the
same environments on which a good Fortran compiler is also already
available.  Since the only reason I can see to use C on scientific
or numerical codes is if Fortran is not available at all.  If the
extensions to C which allow it to generate efficient code were
universally available, then the use of C as an intermediate
language (like NAG Fortran 90 does) would be an acceptable idea.  
I'd personally like to *never* again have to write or maintain C
directly.  Of course, any other intermediate language which was
widely avalable would be acceptable - like an extension of UCSD
p-code for example.  Once you get rid of dorect C use, there's
no reason to have it at all.

Be aware, in addition, that using these special C compiler switches
makes the compiler non-standard conforming.  With sufficient inter-
process analysis, C can be made as efficient as Fortran *without*
making non-standard assumptions.  However, such implementations are
expensive (and rare).

--
J. Giles



Sat, 20 May 1995 06:11:11 GMT  
 C vs Fortran for numerical work

:

:
:    However, my original point still stands.  CRI has proven that you can make C
:    or C++ numerical code as fast as fortran code, without difficulty, and on a
:    complex architecture to boot.  I would hope that workstation compiler vendors
:
: When such compiler flags are employed, the language being compiled is
: no longer C. That is to say, codes written to conform with the
: Standard no longer produce the results specified in the standard.

I suspect that this is a discussion about aliasing, and compiler flags
to C compilers to allow more aggressive vectorization by making stricter
assumptions about pointers.

I would put the issue this way:  If one were to use these flags,
its is not guaranteed that the results of the program conform with
the standard given any arbitrary input data, but there could be
large classes of input data for which it does uphold the standard
interpretation.

Clearly the problem domain is such that this is the case, if people
are using it.

It is also clearly impossible in general for the compiler to figure out
when this is the case, and when it is not, as it would have to know
everything about mathematics and the input data that people know.

Maybe it's time for language designers to recognize this fact, and
allow general "assertions" about input data that optimizers understand.

They already use "assertions" internally, because they know that the
results of some operations can produce only some kinds of data.  So why
not allow the user to give more?

: --
: ----------------------------------------------------------------

: SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
: Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Sat, 20 May 1995 06:35:50 GMT  
 C vs Fortran for numerical work

Quote:


>   However, my original point still stands.  CRI has proven that you can make C
>   or C++ numerical code as fast as fortran code, without difficulty, and on a
>   complex architecture to boot.  I would hope that workstation compiler vendors

>When such compiler flags are employed, the language being compiled is
>no longer C. That is to say, codes written to conform with the
>Standard no longer produce the results specified in the standard.

Excuse me?

I think you're confused about providing the compiler with some
extra information vs changing the semantics of the code!  He indicated
that he used a flag telling the compiler that aliasing did not
take place in the argument list.  This allows a _huge_ amount of optimization
which could not otherwise be safely done.

Think about, you'll get it.

Regards,
DNL

                       MY_COMMENTS = MY_OPINIONS.

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp

(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041



Sat, 20 May 1995 05:59:21 GMT  
 C vs Fortran for numerical work


   :
   : When such compiler flags are employed, the language being compiled is
   : no longer C. That is to say, codes written to conform with the
   : Standard no longer produce the results specified in the standard.

Boy, does this statement have "beaurocrat" written all over it.  The fact is
it works, and makes up for the lack of a more global optimizing facility.  I
don't know about you, but I'm in the business of getting results, whether
that is in Fortran, C, C++, lisp, postscript, or whatever the best tool for
the job is.  And if throwing command line switches means that my C code runs
as fast as a Fortran code, then all the better.  By your reasoning, adding a
"CDIR$ IVDEP" to a Fortran code on a Cray means it is no longer Fortran.
Gee, I guess I'm not using either Fortran or C on Crays.

--

Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]



Sat, 20 May 1995 13:58:36 GMT  
 C vs Fortran for numerical work
On the general topic of using C vs. Fortran for numerical work, I note
that on the massively parallel Connection Machines, a data-parallel C
language called C* (C-star) exists.  This can give excellent
performance.  I understand that ANSI is looking into standardizing
the data-parallel extensions to C.  So C may have a future in high
performance computing after all :-).

With best regards,

Ole H. Nielsen
Laboratory of Applied Physics, Building 307
Technical University of Denmark, DK-2800 Lyngby, Denmark

Telephone: (+45) 42 88 24 88 ext. 3187
Telefax:   (+45) 45 93 23 99



Sat, 20 May 1995 18:28:50 GMT  
 C vs Fortran for numerical work

Quote:
>   :
>   : When such compiler flags are employed, the language being compiled is
>   : no longer C. That is to say, codes written to conform with the
>   : Standard no longer produce the results specified in the standard.

This is bunkum! Using a #pragma to tell the compiler to vectorize
certain loops by ignoring possible dependencies or aliasing is no
different from using similar directives that pepper CRI FORTRAN
programs. It is true that you are making a promise about the data
involved, but so what? The code itself is standard! (By careful
arrangement, however, certain parameters are never aliased in
your code -- that doesn't make the code non-C!) If you also
follow through on your own promises about the assumptions you allow
the compiler to make, your executable is also guaranteed to produce
the results specified by the standard.

In practice, I have found it very easy to keep any promises I make
when using such directives -- that may be a result of having little
or no inclination to provide aliased parameters to a routine.

pju



Sat, 20 May 1995 16:39:10 GMT  
 C vs Fortran for numerical work

Quote:
> When such compiler flags are employed, the language being compiled is
> no longer C. That is to say, codes written to conform with the Standard
> no longer produce the results specified in the standard.

This doesn't seem correct to me.  If the programmer makes some extra
assertions about the program, and the assertions turn out to be true,
then the compiler should use them to produce a faster program but with
identical results.

It's true that one can make false assertions and therefore cause the
compiler to generate incorrect results, but so what?  BTW exactly the
same thing is true of the Cray Fortran compilers, which also need
directives and flags in order to generate fast code, and can also
generate incorrect results if the assertions are incorrect.

                                        David desJardins



Sun, 21 May 1995 01:09:02 GMT  
 C vs Fortran for numerical work

...Maybe it's time for language designers to recognize this fact, and
   allow general "assertions" about input data that optimizers understand.

The ANSI C committee debated this (remember "NOALIAS") and chose to
not include it in the language.

A similar debate occured within X3J3 regarding possible pain and
suffering f90 POINTERS may cause optimizers. It is less clear cut,
because f90 POINTERS were designed to permit automatic analysis; but
not everyone agrees that the design was sufficient.

X3J11.1 may suceed in putting something back into ANSI C; if f90
POINTERS prove to inhibit optimization, X3J3 will (no doubt) attempt
to deal with it in an upcoming revision of the standard.

It is certainly possible to influence Standards groups. Joining and
contributing to the work is the best way. Writing proposals and
passing them off to members of the various working groups is another.

With the exceptions of PL/1 and Algol, I don't know of a language
standards group that has disbanded ;>
--
----------------------------------------------------------------

SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992



Sat, 20 May 1995 18:09:31 GMT  
 C vs Fortran for numerical work


...
   Boy, does this statement have "beaurocrat" written all over it.  The fact is
   it works, and makes up for the lack of a more global optimizing facility.  I

I spent about a decade in the business of moving code from itty-bitty
8-bit micros (Z80 and friends) to largish boxes (e.g. UNIVAC 1108) and
to big machines (e.g. CDC, Cray, etc.).

Relying on outright violations of the relevant language Standards
caused me a lot of expensive suffering.

When you rely on such compiler switches, are you documenting this in
the code? Have you identified precisely the input domain which you
have excluded in each module? If not, someone downstream is likely to
pay the price.

Since X3J11 chose not to include NOALIAS (or provide an alternative
solution) vendors and users have to make their own solutions for each
platform. One shouldn't be confused about the benfits (I certainly am
not!) however, one mustn't neglect to account for the costs too.

Using non-standard features of a language is often a fine thing to do.
I've done it for years. However, it is important to note what one has
done and why.
--
----------------------------------------------------------------

SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992



Sat, 20 May 1995 18:16:28 GMT  
 C vs Fortran for numerical work


Quote:

>I spent about a decade in the business of moving code from itty-bitty
>8-bit micros (Z80 and friends) to largish boxes (e.g. UNIVAC 1108) and
>to big machines (e.g. CDC, Cray, etc.).

>Relying on outright violations of the relevant language Standards
>caused me a lot of expensive suffering.

I daresay these were true violations and not things like directives
to force vectorization :-)

You generally don't violate any language standards by voluntarily
restricting input data! Nor do you violate any standards by giving
the compiler such information with some #pragma's in C or C$dir's
in Fortran.

Quote:

>When you rely on such compiler switches, are you documenting this in
>the code? Have you identified precisely the input domain which you
>have excluded in each module? If not, someone downstream is likely to
>pay the price.

If you don't use the switches, the compiler can't make any assumptions
and the code will work properly (but maybe slower--a lot slower!).
Other than that the rule is simple: don't alias any parameters, and if
you must, make sure it won't matter! You can always check this by
testing with optimizations turned off.

On the other hand, it really isn't that difficult to document what
restrictions the input data must satisfy---only rarely is there any
real complication (nothing much worse than memcopy/memmove in the
ANSI library).

Quote:

>Since X3J11 chose not to include NOALIAS (or provide an alternative
>solution) vendors and users have to make their own solutions for each
>platform. One shouldn't be confused about the benfits (I certainly am
>not!) however, one mustn't neglect to account for the costs too.

The costs need not be significant; the benefits can be enormous
(when it comes to vectorization, etc.).

Quote:

>Using non-standard features of a language is often a fine thing to do.
>I've done it for years. However, it is important to note what one has
>done and why.

A #pragma is the standard way for ANSI C to be nonstandard :)

Quote:
>--
>----------------------------------------------------------------

>SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
>Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992

pju


Mon, 22 May 1995 15:46:13 GMT  
 C vs Fortran for numerical work
Would anybody tell me how to get a file with the storage map out
of the f77 sun compiler?  What I need is a file with the names of
all the variables used in a program module.  I know this
is a very common thing to do with other compilers.  For example, both
VAX fortran and Microsoft fortran have a command line option to generate
such file.
        I would really appreciate any help in this regard.

                        Enrique A. Medina



Tue, 30 May 1995 06:24:38 GMT  
 C vs Fortran for numerical work


   Would anybody tell me how to get a file with the storage map out
   of the f77 sun compiler?  What I need is a file with the names of
   all the variables used in a program module.  I know this
   is a very common thing to do with other compilers.  For example, both
   VAX fortran and Microsoft fortran have a command line option to generate
   such file.
           I would really appreciate any help in this regard.

Load maps are optionally produced by ld. Since ld is invoked for you
automatically, you can pass it the relevent flag via f77:

        f77 -Qoption ld -M  ! solaris 1.x
                        -m  ! solaris 2.x

see man ld for further details.

If what you really want is a cross reference listing, that is -Xlist
with the current (2.0.1) f77 product.
--
----------------------------------------------------------------

SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992



Tue, 30 May 1995 17:46:53 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Fortran vs. C for numerical work

2. Fortran vs. C for numerical work

3. Fortran vs. C 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