This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What is acceptable for -ffast-math? (Was: associative law in combine)



----- Original Message -----
From: "Toon Moene" <toon@moene.indiv.nluug.nl>
To: <dewar@gnat.com>
Cc: <gdr@codesourcery.com>; <torvalds@transmeta.com>; <fjh@cs.mu.oz.au>;
<gcc@gcc.gnu.org>; <moshier@moshier.ne.mediaone.net>;
<tprince@computer.org>
Sent: Tuesday, July 31, 2001 3:57 PM
Subject: Re: What is acceptable for -ffast-math? (Was: associative law
in combine)


> dewar@gnat.com wrote:
>
> > By the way, I said I would be shocked to find a Fortran compiler
that did
> > associative redistribution in the absence of parens. I am somewhat
surprised
> > that no one stepped forward with a counter-example, but I suspect in
fact that
> > there may not be any shocking Fortran implementations around.
>
> Well, that might be because we're on a public list and I, certainly,
am
> not going to name names of competitors.  Granted, I do not have an
> actual proof of a Fortran compiler that substituted (a+b)*c for
a*b+a*c,
> but I have seen those that:
>
> 1. Included an option to ignore parentheses in the source program.
>
> 2. Included an option to use floating point induction variables, i.e.,
>    change:
>
>       DO I = 1, N
>          A(I) = I * 0.1
>       ENDDO
>
>    into:
>
>       T = 0.0
>       DO I = 1, N
>          T = T + 0.1
>          A(I) = T
>       ENDDO
>
The usual meaning of an option to permit floating point induction
variables would be to permit the usage which was covered by the f77
standard and later ruled out, not to introduce them where the source
code is written with integer induction variables.  The Kuck KAP
pre-processors worked the other way, converting the second version into
the first, with documented options provided to prevent it.  That
transformation was often desired to promote parallelizaton.
> In physics, the computational model in itself is often already a
> compromise - if I just confine myself to weather forecasting, which
I'm
> involved with now for about a decade:
>
> 1. Spherical Earth, rotating with constant angular velocity,
> 2. Ignoring compressibility of the air, assuming hydrostatic
equilibrium
>    at all time.
> 3. Ignoring the vertical component of the Coriolis force,
> 4. Constant acceleration of gravity, independent of height.
>
> Now the compromises to make this actually *computable*:
>
> 1. Finite difference discretisation of the continuous equations,
> 2. Filters to damp numerical noise (both in space and time
dimensions),
> 3. Approximations to compute the compound effect of sub-grid scale
>    physics (radiation, phase changes of water, etc.).
>
> Now let's look at the question above, again:
>
> "it did not bother [Cray] that 81.0/3.0 did not give exactly 27.0 on
>  the CDC 6000 class machines."
>
Typical compilers for IA-64 are off frequently by 1 ULP on simple
division calculations at -O3, and on sqrt() at -O2.  This is a normal
consequence of substituting a series of iterations without extra
precision for division.  Some may consider this an excessive reversion
toward the Cray tradition.
>




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]