On 10 Jul 2014, at 18:54, JF Bastien <[email protected]> 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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
