Non-extensibility of Typed Arrays
brendan at mozilla.com
Wed Sep 4 11:33:02 PDT 2013
Filip Pizlo wrote:
> So, how big are your non-expanddable typed arrays, and what do they
> look like? If they're not smaller than 16 bytes in the common case
> with 32-bit pointers, or 32 bytes in the common case with 64-bit
> pointers, then there is no performance argument in favor of getting
> rid of expandable properties.
I like your analysis, it helps greatly to be quantitative and to talk
concretely about implementation trade-offs. However, I don't think it
proves as much as you assert.
Suppose I want (as IBM did for years, and may still) to implement IEEE
754r decimal in JS, with minimal overhead. I would need 128 bits of flat
storage, no variable length, no .buffer or aliasing, and *no expandos*.
Can binary data help me do that? If so, how small can the thing be? I'd
like a multiple of 16 bytes, but on 64-bit targets that does not leave
enough room for TBLR and we don't really need BLR anyway.
If we can't implement efficient-enough 754r decimal using binary data,
that's sad. Not the end of the world, and it doesn't prove a whole lot
about anything (perhaps we'll figure out something next year). But the
small, fixed-size array case exists (think of Float32Array 4-vectors,
homogeneous coordinates). It seems to me you are giving this use-case
More information about the es-discuss