|Re: Why C is much slower than Fortran firstname.lastname@example.org (Daniel Barker) (1999-04-18)|
|Re: Why C is much slower than Fortran email@example.com (Thomas Elken) (1999-04-29)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (Daniel Barker) (1999-04-30)|
|Problems with "ANSI aliasing" [was: Why C is much slower ..] email@example.com (1999-04-30)|
|Re: Problems with "ANSI aliasing" [was: Why C is much slower ..] firstname.lastname@example.org (1999-05-03)|
|Re: Why C is much slower than Fortran email@example.com (Robert Harley) (1999-05-03)|
|Re: Problems with "ANSI aliasing" [was: Why C is much slower ..] firstname.lastname@example.org (1999-05-07)|
|Re: Why C is much slower than Fortran email@example.com (1999-05-09)|
|[14 later articles]|
|From:||Thomas Elken <firstname.lastname@example.org>|
|Date:||29 Apr 1999 00:50:34 -0400|
|References:||<3710584B.1C0F05F5@hotmail.com> <email@example.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:
printf("final calcs: %d, %f, %f\n", nlp, E[jmax][kmax],
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:
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++
alias=name Specifies the pointer aliasing model to be used. By
specifiying one of the following for name, the compiler
able to make assumptions throughout the compilation:
TYPED or NO_TYPED TYPED specifies that pointers of
distinct base types are assumed to
point to distinct, non-overlapping
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
(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.
Return to the
Search the comp.compilers archives again.