typed array strawman proposal
brendan at mozilla.com
Wed Jan 27 10:41:56 PST 2010
On Jan 27, 2010, at 10:36 AM, P T Withington wrote:
> On 2010-01-27, at 13:17, Brendan Eich wrote:
>> On Jan 27, 2010, at 10:15 AM, P T Withington wrote:
>>> On 2010-01-27, at 13:06, Brendan Eich wrote:
>>>> Anyway, we do not want to require exotic techniques. We want to
>>>> allow C++ implementations, which require constants to avoid
>>>> obvious performance hits for no good reason. Competition will
>>>> kill any browser foolish enough to take such hits.
>>> That seems inconsistent with the philosophy that classes can be
>>> syntactic sugar on closures that will be magically optimized.
>> That philosophy cannot possibly implement native GPU-oriented fixed-
>> size machine-int-element-typed arrays!
> I must be missing something. You can optimize:
> new Int16Array(foo, n)
> but not:
> new IndirectArray(foo, 'int', 16, 0);
Not using classes desugaring to closures, no. I mean "no" to either of
the above. Constant is not the issue -- you changed the argument to
one of desugaring to closures.
Closures for hiding private variables may be optimized pretty
efficiently but there's a separate argument about the ultimate
performance of classes not desugared to closures, rather compiled to
more traditional runtime organizations. But that's yet another argument.
My point is that without machine types in JS, you can desugar and
lambda-code until the cows come home but you'll never bottom out in
the necessary machine instructions.
Only native code can do this currently, whether generated by a C++
compiler or even a crazy pattern-matching compiler that tries to
recognize bitwise ops clamping doubles stored in JS Arrays. The
latter, besides being crazy, does not prevent the doubles from
leaking, and again it is not something the spec should cater to, let
Since we want to allow C++ implementations, indeed we expect them to
predominate, we need constant machine-int-type widths. We do not want
to add machine int types to JS itself -- I've seen no proposals
lately, and I'm opposed based on complexity and safety (silent
wraparound vs. overflow to double, but not an overflow exception).
More information about the es-discuss