Re: Floating point performance issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/20/2011 09:24 AM, Vincent Lefevre wrote:
On 2011-12-20 14:57:16 +0100, David Brown wrote:
On 20/12/2011 14:43, Vincent Lefevre wrote:
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.
Really, it should have never been an option since it may produce
incorrect code. Such kinds of optimization should have only been
enabled via pragmas, and only in a well-documented manner so that
the developer can know how this code could be transformed (and
only the developer should be allowed to enable such optimizations).

I would still say that most floating point code does not need such
control, and that situations where it matters are rather
specialised.
I think that if this were true, there would have never been an
IEEE 754 standard.



This argument has been going on since (or before) the IEEE 754 standard was approved. Mathematical purists on one side and just-make-it-run-fast pragmatists on the other. We won't solve it here.

--jeff



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux