Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Fortran computes cosine 300 times faster than C (on Sun3)
Message-ID: <1144@auspex.UUCP>
Date: 10 Mar 89 22:58:07 GMT
References: <765@uceng.UC.EDU> <1989Mar8.234929.9905@utzoo.uucp>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27

>Second, Sun's Fortran optimizer is much better than their C optimizer,

Not in SunOS 4.0; Sun's FORTRAN 1.1 product uses the same "iropt"
optimizer that the SunOS 4.0 68K and SPARC C compiler can use (although
the product may carry its own copy of that optimizer with it).  However,
you have to *ask* for it in the 68K C compiler, by using "-O2"; "-O"
defaults to "-O1", which only runs the peephole optimizer.  (Future
releases may default to "-O2" on 68K-based Suns, as current releases do
on SPARC-based Suns and, presumably, Solbournes.  I can't speak for the
386i, which does not, as far as I know, currently offer the "iropt"
optimizer for C.)  FORTRAN 1.1 defaults to "-O3".

>and it has noticed that you're not *doing* anything with those values
>and deleted the whole computation.  You're timing the C code against
>an empty Fortran loop.

As noted in other articles, even doing "cc -O4" on a Sun probably
wouldn't cause the loop to be eliminated, since the (current) Sun C
compiler doesn't "know" about "cos" - specifically, doesn't know that
it's a "pure" function - and therefore can't safely eliminate calls to
it (or even move them outside the loop).

(Note: do not extrapolate from the use of "(current)" to a conclusion
that future Sun compilers *will* know about "cos", using e.g. the
"__builtin_cos" mechanism described in earlier postings.  "(current)"
was only put there to indicate that future Sun compilers *might* do
this.)