typed array strawman proposal

Brendan Eich 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  
alone mandate.

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 mailing list