[whatwg] Endianness of typed arrays

[John Tamplin]

On Wed, Mar 28, 2012 at 8:50 PM, Glenn Maynard <glenn at zewt.org> wrote:

> Maybe I misunderstood what he was referring to; I was thinking about the
> comparative cost of making, say, a C++ function virtual (added dispatch
> cost).  It wouldn't make calls to functions any more polymorphic--you
> already have many view types that you can pass around, and that wouldn't go
> up.
>
> Anyway, I'd expect the only difference in the ArrayBuffer implementation
> would be to make it look like this:
>
> int16_t Int16Array::get_item(int index)
> {
>     int16_t val = this->buf[index];
> #ifdef BIG_ENDIAN
>     val = byte_swap(val);
> #endif
>     return val;
> }
>
> or equivalent JITted assembly.  The cost of this should be
> small--certainly not 10x.
>
> (Dealing with it in the GPU may be harder, but as others have pointed out,
> it should be possible to put any GPU in little-endian mode, even if it
> requires some cooperation from the vendor to accomplish it.)


I assumed the point Kenneth was making that you objected to was that if you
had Uint16BEArray and Uint16LEArray, so you could have both native (with
Uint16Array being one of them) and specific endian-ness was that you are
introducing polymorphic calls.

Ie,

a = someFunctionReturningUint16ArrayWhichMightBeLEorBE();
a[4] = 100;

the call to store into a might need to call Uint16LEArray or
Uint16BEArray.storeInto under the hood.  If you only ever use one, then the
JIT'er can just assume that one and inline it.  Otherwise, it either has to
make a virtual call based on the actual type or it needs to test the type
-- either way, it is going to be a lot slower than *((uint16_t*)
addressOf(a)) = 100 where addressOf is likely a simple offset calculation.

-- 
John A. Tamplin
Software Engineer (GWT), Google