jfb at chromium.org
Thu Jul 10 09:54:27 PDT 2014
Here are a few thoughts about denorms (a.k.a. subnormals as of 2008) from a
discussion a few months ago with John Mccutchan, Dave Herman, Luke Wagner
and Dan Gohman.
A few facts to start off with:
- The current SIMD proposal doesn't specify how denormals behave.
- ECMA-262 specifies denormal behavior in 8.5: "The remaining
9007199254740990 (that is, 2^53-2) values are denormalised, having the form
- Most CPUs support dernomals, but they're often slow (think 10x–100x
slower than a single FP instruction).
- Other hardware like GPUs don't support denormals.
- ARM NEON doesn't support denormals, and instead flushes to zero, which
means that all SIMD operations aren't denormalized whereas all scalar
- A64 does support denormals, but they're not necessarily fast.
- Most CPUs allow setting denormals-are-zero and/or flush-to-zero as a
floating-point state, affecting SIMD too, but that instruction is often
slow or serializes the FP pipeline.
My opinion is that denormals aren't something people are asking for.
They're actually quite a surprise to most people, who learn about them the
hard way when their application slows to a crawl, and then they learn about
DAZ/FTZ and everything is fine again.
I think the current state of hardware makes it prohibitive to mandate that
denormals be supported outright for scalars, and makes it impossible to
mandate denormals for SIMD since ARMv7 is a major CPU ISA that doesn't
support denormals for SIMD (pure scalar would therefore have to be used).
There's a further issue with adding SIMD in JS where the temporary
polyfills will use scalar instructions, so if denormals exist in scalar but
not SIMD then the polyfills are slightly wrong. I think it's also quite
prohibitive to change the CPU's FP state to have DAZ/FTZ on/off between
scalar and SIMD, and allowing the user to annotate their source with
FTZ-on/FTZ-off will lead to surprising performance pitfalls on some
hardware, and will lead to weird coding where scalar FP and SIMD can't be
My conclusion is therefore that denormals should be left as unspecified for
*both* scalar and SIMD. Change the spec for scalars, and leave as-is for
Realistically implementation will set DAZ/FTZ for the foreseeable future,
and if people ever clamor for them then denormals can be brought back,
assuming the hardware landscape is better in the future.
FWIW there's a similar problem with NaNs, which AFAIK are left as
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss