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

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

[dewar]

<<We're talking here of transformations which we do know able to
drastically change the results.
>>

Words like drastically are not particularly helpful in this discussion,
plain "change" would be just fine.

THe issue is whether the "change" is worth the speed up.

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

[Gabriel Dos_Reis]

| <<We're talking here of transformations which we do know able to
| drastically change the results.
| >>
| 
| Words like drastically are not particularly helpful in this discussion,
| plain "change" would be just fine.

Do you think changing 0.125 to 0.0 is not drastic?  I used
"drastically" to stress on the magnitude or error -- no other
conotation was implied. 

| THe issue is whether the "change" is worth the speed up.

I do fully understand that.

-- Gaby

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

[Linus Torvalds]

On Wed, 1 Aug 2001, Gabriel Dos_Reis wrote:
>
> Do you think changing 0.125 to 0.0 is not drastic?

Ehh. It's 0.125 to 0.125.

Try it yourself.

That's not a "drastic difference", not if you actually do what I
explained. If you don't have access to a x86 machine, maybe you can ask
somebody else to test the following appended for you.

Surprise, surprise, they come out exactly the same. Even down to the bit
representation (in case you care).

Not that I'm arguing that they will _always_ be the same down to the ULP,
but I _am_ arguing that at least on x86 it's actually a safe optimization.
You should disable it for -mieee.

		Linus

----
#include <math.h>

void test(double, double, double);

main()
{
        test(0.5*DBL_MAX, 2*sqrt(DBL_MAX), 2*sqrt(DBL_MAX));
}

void test(double a, double b, double c)
{
        printf("%f\n%f\n", a/b/c, a/(b*c));
}

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

[Gabriel Dos_Reis]

| On Wed, 1 Aug 2001, Gabriel Dos_Reis wrote:
| >
| > Do you think changing 0.125 to 0.0 is not drastic?
| 
| Ehh. It's 0.125 to 0.125.
| 
| Try it yourself.

I ran an actual program on sparc-v8/solaris-2.7.  That machine is
known to operate with a 64-bits for double -- I specically mentionned
that.  Just try it yourself. 

-- Gaby

Re: What is acceptable for -ffast-math?

[Kai Henningsen]

gdosreis@sophia.inria.fr (Gabriel Dos_Reis)  wrote on 01.08.01 in < 15208.15303.748602.738457@perceval.inria.fr >:

> | <<We're talking here of transformations which we do know able to
> | drastically change the results.
> | >>
> |
> | Words like drastically are not particularly helpful in this discussion,
> | plain "change" would be just fine.
>
> Do you think changing 0.125 to 0.0 is not drastic?

That depends entirely on the context, obviously. If it's a pixel position,  
for example, it's completely meaningless.

And anyway you needed to go right to the edge of the data type to do that.  
Calculating on the edge (and needing precision) is precisely the situation  
where you switch optimization *off*.

Sure, with 64 bit floats, that edge is a lot closer than with larger  
types. So?

Some work can't be done with those. So? Some work can't be done with 32  
bit floats, either. Or with ints. Nothing new about that.

MfG Kai

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

[dewar]

a/2.0/2.0 will never yield zero if a is non-zero
a/4.0 may indeed yield zero if a is the smallest number

Indeed if one saw a/2.0/2.0 that's pretty peculiar, and it would not be
unreasonable to guess that the properly of not yielding zero was being
exploited :-)

Re: What is acceptable for -ffast-math?

[Kai Henningsen]

dewar@gnat.com  wrote on 01.08.01 in < 20010801171343.5E207F2B65@nile.gnat.com >:

> a/2.0/2.0 will never yield zero if a is non-zero
> a/4.0 may indeed yield zero if a is the smallest number

If a is the smallest positive number in some floating point type, then I  
would certainly expect both a/2.0 and a/4.0 do the same thing - either  
yield zero or signal underflow.

And I certainly do not see how a second /2.0 can possibly change that.

> Indeed if one saw a/2.0/2.0 that's pretty peculiar, and it would not be
> unreasonable to guess that the properly of not yielding zero was being
> exploited :-)

What buggy idea of floating point does this?!

MfG Kai

Re: What is acceptable for -ffast-math?

[Jeremy Sanders]

Just writing my thoughts here... I write (and use) a fair amount of
numerical code, mostly in the field of astronomical data
analysis/modelling. The proposals to rewrite slower expressions into
faster ones, eg

a/b/c -> a/(b*c)

would be a very useful one for the time consuming codes we run. This is
especially true for the C++ code I write, which needs significant
optimisation after inlining.

The point is, this would be an option which would be explicitly enabled,
and so there's no problem about breaking IEEE standards. In addition, if
one is writing code to handle numbers on the order of the maximum value in
a float/double, then there's a good argument that these types are
inappropriate. Losing, say, a factor of ten in any direction in a floating
point number wouldn't be a problem! As for the extra errors introduced by
rewriting expressions, this wouldn't be a problem: if one needs total
control over floating point, there's no reason to use -ffast-math!

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>  http://www-xray.ast.cam.ac.uk/~jss/
Pembroke College, Cambridge. UK   Institute of Astronomy, Cambridge. UK

Re: What is acceptable for -ffast-math?

[dewar]

<<would be a very useful one for the time consuming codes we run.
>>

Do you have measurements, or is this just a guess?

Re: What is acceptable for -ffast-math?

[Jeremy Sanders]

On Fri, 3 Aug 2001 dewar@gnat.com wrote:

> <<would be a very useful one for the time consuming codes we run.
> >>
>
> Do you have measurements, or is this just a guess?

I'm afraid that's only a guess. If I get some time, I might look at some
of the assembly output and see how often this sort of code occurs.

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>  http://www-xray.ast.cam.ac.uk/~jss/
Pembroke College, Cambridge. UK   Institute of Astronomy, Cambridge. UK

Re: What is acceptable for -ffast-math?

[dewar]

<<If a is the smallest positive number in some floating point type, then I
would certainly expect both a/2.0 and a/4.0 do the same thing - either
yield zero or signal underflow.
>>

Please review the IEEE standard

(and please remember rounding!)

>>What buggy idea of floating point does this?!

Please make absolutely sure you understand the issue before deciding this
is a bug :-)