Re: endianness (was: Observability of NaN distinctions — is this a concern?)

Kenneth Russell kbr at
Mon Apr 1 19:24:38 PDT 2013

On Sun, Mar 31, 2013 at 1:42 PM, Kevin Gadd <kevin.gadd at> wrote:
> One could also argue that people using typed arrays to alias and munge
> individual values should be using DataView instead. If it performs poorly,
> that can hopefully be addressed in the JS runtimes (the way it's specified
> doesn't seem to prevent it from being efficient).

Agreed. DataView's methods are all simple and should be easy to
optimize. Because they include a conditional byte swap, they can't run
quite as fast as the typed arrays' accessors -- but they shouldn't
need to. DataView was designed to support file and network I/O, where
throughput is limited by the disk or network connection. The typed
array views were designed for in-memory assembly of data to be
submitted to the graphics card, sound card, etc., and must run as fast
as possible.

> -kg
> On Sun, Mar 31, 2013 at 1:37 PM, Vladimir Vukicevic <vladimir at>
> wrote:
>> (Apologies for breaking threading -- subscribed too late to have original
>> message to reply to.)
>> David Herman wrote:
>> On Mar 27, 2013, at 6:51 AM, Andreas Rossberg <rossberg at>
>> wrote:
>> > There actually are (third-party) projects
>> > with ports of V8 and/or Chromium to big endian architectures.
>> It would be helpful to have more information about what these platforms
>> and projects are.
>> The Wii-U is probably the highest profile example of this; PowerPC base,
>> and they're doing a bunch of HTML5 apps stuff like what they announced at
>> GDC.
>> > WebGL
>> > code should not break or become prohibitively expensive on them all of
>> > a sudden.
>> But WebGL code doesn't break either way. It's if we *don't* mandate
>> little-endian that
>> code breaks. As for the expense, it has to be weighed against content
>> breaking. Not to
>> mention the burden it places on developers to write portable code without
>> even having
>> big-endian user agents to test on. (I suppose they could use DI and shim
>> the typed array
>> constructors with simulated big-endian versions. Ugh...)
>> The problem, as I see it at least, is that if little-endian is mandated,
>> then effectively we *have* broken WebGL, or the possibility o ever having
>> performant WebGL on those platforms.  The underlying OpenGL API will always
>> be native-endian.  While big-endian processors often do have ways of
>> efficiently doing byte-swapped loads and stores, that doesn't apply to
>> passing bulk data down.  For example, vertex skinning is the base method of
>> doing skeletal animation.  It's often done on the CPU, and it involves
>> transforming a bunch of floating point data.  The result is then uploaded to
>> the GPU for rendering.
>> If typed arrays are fixed to be little endian, that means that on big
>> endian platforms one of two things will need to happen:
>> - the application will need to manually byte swap (in JS) by aliasing the
>> Float32Array as a UInt8Array and twiddling bytes.
>> - the WebGL implementation will need to make a copy of every incoming > 1
>> byte element size buffer and do the byte swapping before passing it down to
>> GL -- it can either allocate a second buffer, swap into it, and then throw
>> it away, or it can swap before the GL call and unswap after the GL call
>> in-place.

If the typed array views are specified to be little-endian, the latter
is what would need to be done in order to allow existing content to
run. I agree that this would make WebGL unusably slow on big-endian


>> Both of these are essentially murder for performance; so by attempting to
>> prevent code from breaking you're basically guaranteeing that all code will
>> effectively break due to performance -- except that developers have no
>> option to write portable and performant code.
>> The other thing is, I suspect that a large chunk of code using typed
>> arrays today will work just fine on big endian platforms, provided that the
>> arrays are defined to be native-endian.  Very few code actually aliases and
>> does munging; the only issues might come up with are loading data from the
>> network, but those are present regardless.
>>     - Vlad
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> --
> -kg
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list