[whatwg] Endianness of typed arrays

[Glenn Maynard]

On Wed, Mar 28, 2012 at 7:11 PM, John Tamplin <jat at google.com> wrote:

> On Wed, Mar 28, 2012 at 8:04 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> > The result was increased polymorphism at call sites, which defeated the
>> Java VM's
>> > optimizing compiler and led to 10x slowdowns in many common
>> > situations.
>>
>> FWIW, I think this has no bearing at all on JS.
>>
>
> Check out this blog post about optimization in V8, in particular the
> difference between monomorphic and polymorphic calls and the effect on
> inlining:


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.)

-- 
Glenn Maynard