Re: Why C is much slower than Fortran

Thomas Elken <telken@sgi.com>
29 Apr 1999 00:50:34 -0400

          From comp.compilers

Related articles
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-04-18)
Re: Why C is much slower than Fortran telken@sgi.com (Thomas Elken) (1999-04-29)
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-04-30)
Problems with "ANSI aliasing" [was: Why C is much slower ..] trt@cs.duke.edu (1999-04-30)
Re: Problems with "ANSI aliasing" [was: Why C is much slower ..] bglbv@my-dejanews.com (1999-05-03)
Re: Why C is much slower than Fortran harley@corton.inria.fr (Robert Harley) (1999-05-03)
Re: Problems with "ANSI aliasing" [was: Why C is much slower ..] zalman@netcom.com (1999-05-07)
Re: Why C is much slower than Fortran hrubin@stat.purdue.edu (1999-05-09)
[14 later articles]
| List of all articles for this month |

From: Thomas Elken <telken@sgi.com>
Newsgroups: comp.lang.c++,comp.lang.fortran,comp.compilers
Date: 29 Apr 1999 00:50:34 -0400
Organization: Silicon Graphics
References: <3710584B.1C0F05F5@hotmail.com> <7esvkr$v8g$1@camel29.mindspring.com> <37122569.BF79CD19@hotmail.com> <3712311D.BA9027D4@hotmail.com> <7etenl$nk5$1@alexander.INS.CWRU.Edu> 99-04-048
Keywords: C, Fortran, performance

Daniel Barker wrote:
> Firstly, on a Sun SPARCcenter 2000, using GNU C as "gcc -O4", Sun C as
> "cc -fast" and Sun FORTRAN 77 as "f77 -fast", I got:
>
> GNU C: 16.4 seconds
> Sun C: 8.5 seconds
> Sun FORTRAN: 5.4 seconds
>
> Much more interestingly, I repeated it on a SGI PowerChallenge, using MIPS
> C as "cc -Ofast" and MIPS FORTRAN 77 as "f77 -Ofast", and got:
>
> C: 0.01 seconds
> FORTRAN: 0.01 seconds
>
> I assume the MIPS compilers correctly note that the results of the loop
> are irrelevant to program output, and remove the loop entirely.


Correct you are. The SGI MIPSpro compiler is too smart.


I inserted a line of output at the end to get it to do some work:


C:
printf("final calcs: %d, %f, %f\n", nlp, E[1][jmax][kmax],
E[imax][jmax][kmax]);
FORTRAN:
            write(6,*) 'final calcs: ', nlp, E(1,jmax,kmax), E(imax,jmax,kmax)


and compiled as you did ( -Ofast) and got these times:


C: 0.46 seconds (real time)
FORTRAN: 0.48 seconds


on an Octane, MIPS R10000, 195MHz


-Ofast is really a bundle of compiler options:
The important one for this discussion is:
-OPT:alias=typed


The OPT:alias options can make code with C arrays or pointers run as
fast as FORTRAN with arrays, if they use pointers correctly. We have
many examples of this being true. Some of SGI's math libraries (complib
or SCSL) are written in C. I am tuning one such C code for solving
sparse linear equation systems which achieves 520 Mflops on one
processsor out of a 600 Mflops peak (on a somewhat dense matrix).
Maximum on a BLAS matrix multiply kernel (written in assembler) is about
550 Mflops on the same R12000 processor.


The definition of *some* of the alias options for the MIPSpro C/C++
compiler are:


          Suboptions Action


          alias=name Specifies the pointer aliasing model to be used. By
                                  specifiying one of the following for name, the compiler
is
                                  able to make assumptions throughout the compilation:


                              name Assumption


                              TYPED or NO_TYPED TYPED specifies that pointers of
                                                                                distinct base types are assumed to
                                                                                point to distinct, non-overlapping
                                                                                objects.


                                                                                NO_TYPED specifies that pointers to
                                                                                different base types may point to
                                                                                the same object.


                                                                                (C and C++ only)


                              RESTRICT or NO_RESTRICT RESTRICT specifies that distinct
                                                                                pointers are assumed to point to
                                                                                distinct, non-overlapping objects.


                                                                                NO_RESTRICT specifies that distinct
                                                                                pointers may point to overlapping
                                                                                storage.


                                                                                (C and C++ only)




> Such excellent optimization aside, the program is unusual, in that it
> theoretically has no reason to run faster in either C or FORTRAN.


The program is not that unusual. A good compiler and well written C
(but no need to avoid pointers) can match FORTRAN performance.




Regards,
Tom Elken


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.