Author: Eugene Nalimov
Date: 18:18:45 09/10/02
Go up one level in this thread
Lot of compilers, including Visual C, can produce either fast but
non-IEEE-compliant, or relatively slow, but consistent code. It happens that lot
of people are ready to lost some FP accuracy but gain some speed in return.
Several trivial examples of the numerically unsafe but common optimizations:
Replacing division by loop-invariant value by multiplication, i.e.
for (i=0; i<100; i++)
a[i] = b[i]/x;
would be replaced by
y = 1./x;
for (i=0; i<100; i++)
a[i] = b[i]*x;
Expression reordering:
x = a+b+c+d;
would be replaced by
x = (a+b)+(c+d);
Reductions:
for (i=0; i<100; i++)
s += a[i]*b[i];
would be replaced by
s1 = 0.0;
for (i=0; i<100; i+=2) {
s += a[i]*b[i];
s1 += a[i+1]*b[i+1];
}
s += s1;
Removing multiplications by zero, additions with zero, etc. Surprisingly, those
optimizations should not be done by the IEEE-compliant compiler!
And of course there are "real" optimizations done by "real" heavy-FP-optimizing
compilers -- blocking, peeling, etc.
Thanks,
Eugene
On September 10, 2002 at 20:04:16, Robert Hyatt wrote:
>On September 10, 2002 at 19:41:53, Dieter Buerssner wrote:
>
>>On September 09, 2002 at 23:10:20, Robert Hyatt wrote:
>>
>>>I can't believe _any_ compiler would use .001 since it can't be converted
>>>to IEEE FP exactly. Dividing by 1000 is far more preferable as 1000 _can_
>>>be converted exactly.
>>
>>gcc -ffast-math
>>
>>Often (mostly?) this is nice. For example
>>
>> double a, b, c, d;
>>
>> /* I don't care about the last bit (only this can be different), but about
>> speed */
>> a /= d;
>> b /= d;
>> /* Or should I write:
>> c = 1.0/d;
>> a *= c;
>> b *= c;
>> A clever compiler may know, which is faster for this specific architecture.
>> Many algorithms will work well either way, so one prefers the fastest method.
>> A strict IEEE-conforming floating point environment, of course must not
>> rearrange such expressions.
>> */
>>
>>Regards,
>>Dieter
>
>That is a different issue IMHO. IE certainly you want to avoid divisions on
>the Cray since it could not divide. In fact, it had a "reciprocal
>approximation" instruction that computed 1/x to whatever accuracy you wanted.
>
>But if I give a compiler the /10 type operation, it should prefer that to
>*.1, because the /10 has enough error in it, the *.1 adds move because it
>is non-representable in a perfect conversion.
>
>I was commenting about the compiler arbitrarily replacing /1000.0 with
>*.001, which would seem to be bad math...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.