Floating point performance issue

David Brown david@westcontrol.com
Tue Dec 20 14:25:00 GMT 2011

On 20/12/2011 14:43, Vincent Lefevre wrote:
> On 2011-12-20 14:01:19 +0100, David Brown wrote:
>> There are times when you want IEEE-accurate floating point, because you are
>> pushing the limits of accuracy, or you want high repeatability.  But
>> normally when you use floating point, you are accepting a certain amount of
>> inaccuracy.  If your code is going to produce incorrect answers because of
>> the way the compiler/cpu rounds calculations, orders your sums, or treats
>> denormals and other specials, then I would argue that your code is probably
>> wrong - perhaps you should be using decimal types, long doubles, __float128,
>> or some sort of multi-precision maths library instead.
> I disagree: the operations could be written in an order to avoid some
> inaccuracies (such as huge cancellations) or to emulate more precision
> (e.g. via Veltkamp's splitting) or to control the rounding (see some
> rint() implementation http://sourceware.org/bugzilla/show_bug.cgi?id=602
> for instance). On such code, unsafe optimizations could yield problems.

I guess that's why it's an option - then we can choose.  I would still 
say that most floating point code does not need such control, and that 
situations where it matters are rather specialised.  But that's just my 
unfounded opinion - judging from your signature you /do/ need such tight 
control in your work, while I've only learned today that "-ffast-math" 
has effects other than possibly changing the generated code.

More information about the Gcc-help mailing list