[Public WebGL] NaN handling in Typed Array spec

Kenneth Russell [email protected]
Tue Feb 8 14:57:34 PST 2011

On Mon, Feb 7, 2011 at 8:21 PM, Andreas Gal <[email protected]> wrote:
> I can't speak for TC39, but I can pretty much promise you they would seriously hate this because it exposes architecture dependent platform bits to the JavaScript language and you can end up with all sorts of strange incompatibilities.
> I don't think its particularly expensive to normalize NaNs when writing them out. For sufficient large quantities the memory traffic probably dominates the extra execution cycles. That having said, I would be much more concerned about reading data via Float*Array that was written as a bit stream. Unusual NaN values can cause substantial performance penalties on most modern processors. And then there are signaling NaNs in some FPU implementations, which can be a headache, too.

The TC39 has already expressed displeasure with the Typed Array
specification and is developing alternative functionality. I and
others perceive value in having a high-performance data processing API
available in browsers today, so we are continuing to refine the Typed
Array specification and implementations.

I'm not willing to impose any unnecessary performance constraints on
the Typed Array setters and getters, and in particular for storing
NaNs I don't see any value in requiring a particular bit pattern to be
stored. You're absolutely right that loads from floating-point typed
arrays require extra processing to ensure that the ECMAScript engine
doesn't load values it can't handle, but given the design of the typed
array spec this is unavoidable.

> The above issues aside I don't see any major problems with either specification text for our specific implementation.

OK, thanks. That's good to know.


> Andreas
> On Feb 7, 2011, at 8:08 PM, Vladimir Vukicevic wrote:
>> I don't think so; pretty sure we discussed this at Mozilla and decided that there was no issue.  Cc'ing Andreas to make sure, though.  The only tricky thing is that implementations need to make sure that they can handle various NaNs (including signalling ones) creeping into the rest of the engine.
>>   - Vlad
>> ----- Original Message -----
>>> A bug was recently filed against WebKit's implementation of Typed
>>> Arrays (https://bugs.webkit.org/show_bug.cgi?id=53598). The basic
>>> issue is that the Web IDL specification defines the bit pattern for
>>> the not-a-number (NaN) value. Ordinarily, it is not possible for
>>> ECMAScript programs to examine this bit pattern, but with the
>>> introduction of the Typed Array specification, it is possible to use a
>>> Float32Array to store NaN and then read back the bytes using, for
>>> example, a Uint8Array.
>>> Some ECMAScript engines use multiple representations for NaN
>>> internally, and forcing them to be canonicalized into a single bit
>>> pattern would impose a significant performance penalty on all stores
>>> into Float32Arrays. It is absolutely essential for WebGL programs that
>>> loads from and stores into Float32Arrays remain as performant as
>>> possible.
>>> I would like to add a small, normative section to the Typed Array
>>> specification indicating that the bit pattern for NaN values stored
>>> using Float32Array, Float64Array and DataView is not specified, and
>>> that implementations may utilize any of the legal NaN bit patterns
>>> defined by the IEEE-754 specification. I do not believe that doing so
>>> would introduce any significant ambiguity into the spec; this is a
>>> small corner case.
>>> Are there any comments on this proposal?
>>> -Ken
>>> -----------------------------------------------------------
>>> You are currently subscribed to [email protected]
>>> To unsubscribe, send an email to [email protected] with
>>> the following command in the body of your email:
>>> unsubscribe public_webgl
>>> -----------------------------------------------------------

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list