This is the mail archive of the 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: Draft "Unsafe fp optimizations" project description. wrote:
> Tim asks:
> <<Are you suggesting that abrupt underflow, on systems which
> have such an option, should be a -ffast-math option?
> >>
> First, a general point, I think it is important that everyone looking
> at this issue be sure they understand the importance of denormals. Some
> of the input has been in the "well I don't see it could make much difference
> whether I get denormals or abrupt underflow", and if that were generally
> true, the argument for putting denormals into IEEE would never have succeeded,
> since it was strongly opposed by hardware designers. The burden of proof
> of utility for denormals was pretty heavy, but met, so it is a good idea
> to fully understand the issue.

Let me show you another side of this issue :-)

The first time I got the idea that our NWP code was spending 45 % of its
time in kernel mode due to denormals, I immediately thought:  "Oh God -
an error; probably due to someone using an uninitialised variable",
because that's how we routinely run into non-finites (Inf's, Nan's and -
less easily detectable - denormals).

When I actually analysed it, it turned out to be something like the

Someone needed to program the <insert-unpronouncable-German-name-here>
effect in the formation of precipitation in cumulus clouds.  After some
exercises with gnuplot and the original data, he finds that exp(-a.T)
fits the curve (a constant, T temperature).  Great !  It nicely drops of
to zero, exactly (well ...) as the real phenomenon.  Unfortunately, like
most of my colleagues, he didn't realize that for suitable values of T,
this would produce denormals ...  So the outcome of the computation is
OK - the denormal result vanishes w.r.t. to the other terms so it could
just as well be zero.

Unfortunately, on the system he works on, the kernel traps now start to
form a noticable performance problem.

Toon Moene - - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77:
Join GNU Fortran 95: (under construction)

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