RE: Observability of NaN distinctions — is this a concern?

Hudson, Rick rick.hudson at intel.com
Tue Mar 26 08:06:06 PDT 2013


> <jussi.kalliokoski at gmail.com>
> wrote:
>
> That's just because ES has had no notion of bits for floating points before.
> Other than that, ES NaN works like IEEE NaN, e.g.
>

Some background about the latest GLS spec and IEEE NaNs from http://www.opengl.org/registry/doc/GLSLangSpec.4.20.11.clean.pdf

Section 4.1.4 states
"As an input value to one of the processing units, a single-precision or double-precision floating-point
variable is expected to match the corresponding IEEE 754 floating-point definition for precision and
dynamic range. Floating-point variables within a shader are also encoded according to the IEEE 754
specification for single-precision floating-point values (logically, not necessarily physically)."

Section 4.7.1 goes on to provide a detailed list of reduced (from IEEE 754) precision requirements 
for single precision floats and then states the following:
"The precision of double-precision operations is at least that of single precision."

4.7.1 also sets up the requirements of operations to produce NaNs as follows:
" NaNs are not required to be generated. Support for signaling NaNs is not required and
exceptions are never raised. Operations and built-in functions that operate on a NaN are 
not required to return a NaN as the result."

So any statement that the GLS spec follows IEEE 754 treatment of double precision is only a 
statement about input values.

- Rick


-----Original Message-----
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Andreas Rossberg
Sent: Tuesday, March 26, 2013 6:40 AM
To: Oliver Hunt
Cc: Mark S. Miller; Brendan Eich; es-discuss
Subject: Re: Observability of NaN distinctions — is this a concern?

I'm with Dave and Oliver. Worrying about the performance cost of NaN normalisation has a strong smell of premature micro optimisation. The one branch per float store, whose cost should be amortised by branch prediction when frequent, seems very unlikely to be measurable compared to everything else going on when executing JavaScript.

As for the "this is not a common problem" argument, use cases should only trump principles if the cost is unbearable.

/Andreas


On 26 March 2013 09:29, Oliver Hunt <oliver at apple.com> wrote:
>
> On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski 
> <jussi.kalliokoski at gmail.com>
> wrote:
>
> That's just because ES has had no notion of bits for floating points before.
> Other than that, ES NaN works like IEEE NaN, e.g.
>
> 0/0 === NaN // false
> isNaN(0/0) // true
>
>
> That's true in any language - comparing to NaN is almost always 
> defined explicitly as producing false.  You're not looking at bit 
> patterns, here so conflating NaN compares with bit values is kind of pointless.
>
>
>
>
>
>>
>>
>>
>>>
>>>
>>>>
>>>> We need to stop raising "this causes performance problems" type 
>>>> issues without a concrete example of that problem.  I remember 
>>>> having to work very hard to stop WebGL from being a gaping security 
>>>> hole in the first place and it's disappointing to see these same 
>>>> issues being re-raised in a different forum to try and get them bypassed here.
>>>
>>>
>>> Before saying security hole, please elaborate. Also, when it comes 
>>> to standards, I think change should be justified with data, rather 
>>> than the other way around.
>>
>>
>> Done.
>
>
> You'll have to do better than that. ;)
>
>
> Ok, I'll try to go over this again, because for whatever reason it 
> doesn't appear to stick:
>
> If you have a double-typed array, and access a member:
> typedArray[0]
>
> Then in ES it is a double that can be one of these values: 
> +Infinitity, -Infinity, NaN, or a discrete value representable in IEEE double spec.
> There are no signaling NaNs, nor is there any exposure of what the 
> underlying bit pattern of the NaN is.
>
> So the runtime loads this double, and then stores it somewhere, 
> anywhere, it doesn't matter where, eg.
> var tmp = typedArray[0];
>
> Now you store it:
> typedArray[whatever] = tmp;
>
> The specification must allow a bitwise comparison of 
> typedArray[whatever] to typedArray[0] to return false, as it is not 
> possible for any NaN-boxing engine to maintain the bit equality that 
> you would otherwise desire, as that would be trivially exploitable.  
> When I say security and correctness i mean it in the "can't be remotely pwned" sense.
>
> Given that we can't guarantee that the bit pattern will remain 
> unchanged the spec should mandate normalizing to the non-signalling NaN.
>
> --Oliver
>
>
>
> Cheers,
> Jussi
>
>>
>>
>>
>>>
>>>
>>> Cheers,
>>> Jussi
>>>
>>>>
>>>> --Oliver
>>>>
>>>> > Allen
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >>
>>>> >> /be
>>>> >>
>>>> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <kbr at google.com> wrote:
>>>> >>
>>>> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich 
>>>> >>> <brendan at mozilla.com>
>>>> >>> wrote:
>>>> >>>> Allen Wirfs-Brock wrote:
>>>> >>>>>
>>>> >>>>> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
>>>> >>>>>
>>>> >>>>>> Allen Wirfs-Brock wrote:
>>>> >>>>>>>
>>>> >>>>>>> BTW, isn't cannonicalization of endian-ness for both 
>>>> >>>>>>> integers and floats a bigger interop issue than NaN 
>>>> >>>>>>> cannonicalization?  I know this was discussed in the past, 
>>>> >>>>>>> but it doesn't seem to be covered in the latest Khronos 
>>>> >>>>>>> spec.  Was there ever a resolution as to whether or not 
>>>> >>>>>>> TypedArray [[Set]] operations need to use a cannonical 
>>>> >>>>>>> endian-ness?
>>>> >>>>>>
>>>> >>>>>> Search for "byte order" at
>>>> >>>>>> https://www.khronos.org/registry/typedarray/specs/latest/.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> I had already search for "endian" with similar results.  It 
>>>> >>>>> says that the default for DataViews gets/sets that do not 
>>>> >>>>> specify a byte order is big-endean. It doesn't say anything 
>>>> >>>>> (that I can find) about such accesses on TypedArray 
>>>> >>>>> gets/sets.
>>>> >>>>
>>>> >>>>
>>>> >>>> Oh, odd -- I recall that it used to say little-endian. Typed 
>>>> >>>> arrays are LE to match dominant architectures, while DataViews 
>>>> >>>> are BE to match packed serialization use-cases.
>>>> >>>>
>>>> >>>> Ken, did something get edited out?
>>>> >>>
>>>> >>> No. The typed array views (everything except DataView) have 
>>>> >>> used the host machine's endianness from day one by design -- 
>>>> >>> although the typed array spec does not state this explicitly. 
>>>> >>> If desired, text can be added to the specification to this 
>>>> >>> effect. Any change in this behavior will destroy the 
>>>> >>> performance of APIs like WebGL and Web Audio on big-endian 
>>>> >>> architectures.
>>>> >>>
>>>> >>> Correctly written code works identically on big-endian and 
>>>> >>> little-endian architectures. See 
>>>> >>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for 
>>>> >>> a detailed description of the usage of the APIs.
>>>> >>>
>>>> >>> DataView, which is designed for input/output, operates on data 
>>>> >>> with a specified endianness.
>>>> >>>
>>>> >>> -Ken
>>>> >>> _______________________________________________
>>>> >>> es-discuss mailing list
>>>> >>> es-discuss at mozilla.org
>>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> _______________________________________________
>>>> >> es-discuss mailing list
>>>> >> es-discuss at mozilla.org
>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>
>>>> >
>>>> > _______________________________________________
>>>> > es-discuss mailing list
>>>> > es-discuss at mozilla.org
>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list