[music-dsp] Re: floating point running sum optimization
richarddobson at blueyonder.co.uk
Mon Nov 24 17:35:00 EST 2003
Evaluation of sub-expressions is a separate issue from precedence.
Expressions at the same precedence level are evaluated left to right
(mostly; = is evaluated right to left, for example ), but the
expressions themselves (if in the form of sub-expressions) may be
evaluated in different orders by the compiler.
a + b - c is therfore mandated to be evaluated as (a+b) - c
In what order a, b and c are each evaluated ~as expressions~ is another
matter. It is well if c does not have side-effects impacting on b or a,
or vice versa, etc.
I think that it is always a good idea to use explicit brackets anyway,
as part of self-documentation. Brackets cost nothing.
In the case of a + b - b I would suspect the optimiser first of all
(and especially M$s one!). Possibly, some "obvious" optimisations are
done even in debug builds?
Ross Bencina wrote:
> I kind of agree with your "letter of the spec" comment, however I think most
> people doing numerical stuff in C (or C++) expect a high degree of standards
> conformance in this area. If it's not needed there is usually
> a --fast-floating-point flag. Unfortunatly my ANSI C standard is boxed away,
> but I would be surprised if there isn't a clause which says something like
> "evaluation order is non-specified but the results should be the same as if
> the order was as written (left to right as Laurent said). Compiler text
> books usually make it pretty clear that reordering optimisations on floating
> point expressions is a dangerous business and that (a + b) - c is usually
> not equivalent to a + (b - c). Anyhow, I'll shut up now, no point defending
> the gospel without a bible in hand.
More information about the music-dsp