jens at nockert.se
Thu Jul 10 10:22:30 PDT 2014
On 10 Jul 2014, at 18:54, JF Bastien <jfb at chromium.org> wrote:
> Other hardware like GPUs don't support denormals.
Not true, AMD and nVidia GPUs support denormals. Anything that supports double-precision in OpenCL will support denormals.
> 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 programmers are surprised when denormals are slow (but only DSP-type code tends to produce these issues.)
On the other hand, I think most programmers would be surprised if x - y = 0 didn’t mean x == y too.
> 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).
Sure, allow flush-to-zero for SIMD. It doesn’t break old code.
> 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 mixed.
Sure, if you use SSE2 for scalar arithmetic, it shares state with any SIMD extension to JS. So if we really care about the cost of changing the state, we need to use the same state for SIMD and scalar code. (But on modern x86, denormals are relatively fast)
> 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 SIMD.
> 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.
Please, please don’t try to break the web, denormals/gradual underflow change behaviour in a lot of simulations and root-finding problems, there’s already code out there that depends on denormals.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss