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 <oli...@apple.com> wrote: > > On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski <jussi.kallioko...@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 <k...@google.com> wrote: >>>> >> >>>> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <bren...@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@mozilla.org >>>> >>> https://mail.mozilla.org/listinfo/es-discuss >>>> >> _______________________________________________ >>>> >> es-discuss mailing list >>>> >> es-discuss@mozilla.org >>>> >> https://mail.mozilla.org/listinfo/es-discuss >>>> >> >>>> > >>>> > _______________________________________________ >>>> > es-discuss mailing list >>>> > es-discuss@mozilla.org >>>> > https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> >> -- >> Cheers, >> --MarkM > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
