This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Floating point performance issue


Dunno about that(*), but you can portably do

fesetround(FE_TOWARDZERO);

and that prevents the problem from occurring as well.

But this is a bad idea in general, as it would affect all FP operations,
not just subnormals (when one gets subnormals, one has already lost much
precision, so that FTZ may not be a problem in practice -- this depends
on the application, of course).

*Any* specific rounding mode is a bad idea *in general*. It all depends on your algorithm. The same is true for flush-to-zero: for some algorithms it is great, for others it is disastrous.

For the OP's example, rounding towards zero does not give less
precise results.  To get accurate results requires (much) more
work.

In either case, the OP has his answer: the big slowdown he is
seeing is because his CPU handles calculations with denormals
much more slowly than it handles normal numbers.  And in this
thread various ways to avoid denormals have been pointed out.
Which of those is best for his particular actual problem is not
something we can answer.


Segher



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]