On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock <[email protected]> wrote:
> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote: > >> Right, thanks for the reminder. It all comes back now, including the "how to >> write correct ending-independent typed array code" bit. > > Ok, so looping back to my earlier observation. It sounds like endian-ness > can be observed by writing into an Float64Array element and then reading back > from a Uint8Array that is backed by the same buffer. If there is agreement > that this doesn't represent a significant interoperability hazard can we also > agree that not doing NaN cannonicalization on writes to FloatXArray is an > even less significant hazard and need not be mandated? > The reason I have pushed for NaN canonicalization is because it means that it allows (and in essence requires) that typedArray[n] = typedArray[n] can modify the bit value of typedArray[n]. An implementation _may_ be able to optimize the checks away in some cases, but most engines must perform checks on read unless they can prove that they were the original source of the value being read. Forcing canonicalization simply means that you are guaranteed that a certain behavior will occur, and so won't be bitten by some tests changing behavior that you may have seen during testing. I know Ken hates these sorts of things, but seriously in the absence of a real benchmark, that shows catastrophic performance degradation due to this, simply saying "this is extra work that will burn cpu cycles" without evidence is a waste of time. Also there is absolutely no case in which abstract performance concerns should ever outweigh absolute security and correctness bugs. 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. --Oliver > Allen > > > > >> >> /be >> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <[email protected]> wrote: >> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
