Floating point performance issue

[David Brown]

On 26/12/11 01:58, Vincent Lefevre wrote:
> On 2011-12-24 12:02:24 +0100, David Brown wrote:
>> And (regarding other examples in your posts) if floating-point code
>> depends on things like the order of calculations, it is also wrong -
>> thus "-ffast-math" will not affect the correctness of the program,
>> but will sometimes greatly improve the speed.
>
> Whether you like it or not, a floating-point result does depend on the
> order of calculations in general. How would you write code to compute
> the mathematical expression a + b - c where you know that you have the
> property 1/2<= a/c<= 2 on the inputs? Or code to compute a*a - b*b
> where a and b are close to each other? With the IEEE 754 rules, one
> can use formulas that give very accurate results, but if the compiler
> is allowed to rewrite the code (without control from the developer who
> wrote the code), the results may no longer be accurate (and may even
> be quite wrong).
>

If it matters that "a + b - c" be calculated "(a + b) - c" or "a + (b - 
c)", then use brackets.  That what you show the compiler and people 
reading the code what's going on.  In my type of programming, if you 
need to be sure of precise calculations, you always use integer 
arithmetic - it's clear and well-defined, with no scope for 
inaccuracies, rounding errors, etc.  And it's not uncommon that you have 
to use brackets like this to ensure everything works out correctly.

In your example, I don't see how a difference in the ordering of 
calculations will make a difference to the result of more than an LSB or 
two unless there were wildly differing magnitudes involved.  And that's 
something to avoid - you are never going to get accurate results by 
adding or subtracting values of wildly different magnitudes in floating 
point.  You may be able to get consistent, precise, well-defined, 
portable results - but you will not get correct or meaningful results.

My point is that you have to take that kind of effect into account when 
writing the algorithm and the code.  To my mind, it doesn't make sense 
to add a distance in kilometres to a distance in nanometres and expect 
sensible results.  If you have a situation where what is called for 
(maybe you work are CERN), then you are probably better off storing all 
your distances as int64_t femometer units.


>> I don't think I'm alone in wishing that more programmers used stricter
>> coding practices
>
> On the contrary, we are very strict on coding practices in order to
> get accurate results.
>

I realise that, but I don't think you count as "most programmers" in 
this sense - as far as I can tell, you have rather specialised needs. 
You have different requirements than mine, but at least as strict.