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
