On Oct 30, 2013, at 1:56 PM, Luke Wagner <l...@mozilla.com> wrote:

> Just to be sure, do you agree that both the {lo, hi}-returning API and the 
> magic-property API should both be able to achieve equivalent performance on a 
> JS engine that has specifically added and optimized these int64 builtins?  I 
> think this is true.
> Assuming so, the reason to prefer the rather more awkward magic-property API 
> would be purely because its polyfill is more efficient.  This is a tough 
> choice, but it seems like bending the spec for the polyfill is overly 
> conservative in this case.  A lot of the use cases I hear for int64 come from 
> crypto and other very specific algorithms which already have implementations 
> in JS.  In such cases, it seems like the authors have to write a new version 
> of the algorithm using the new builtins anyway so, if performance was 
> important, they could just keep around the old version and pick which version 
> to call based on whether the new builtins are present.  Or they can just wait 
> until the optimization is broadly available before switching.

Agreed -- the magic-property API is pretty astoundingly wacky, and definitely 
not worth it.

> The other main use case I can think of is large compiled C++ codebases.  
> However, in our experience, C++ codebases tend not to heavily use int64 so 
> the overhead of the polyfill would be less significant.

I'm open to the {lo, hi} version of the API as a stopgap, but since we don't 
see a big need for it in compiled codebases and it's warm beer for human 
programmers, then looking at Slava's rationale...

> I think such API has many advantages:
> - can greatly improve performance of numeric algorithms relying on 64-bit 
> math;
> - easily polyfillable in the current JavaScript;
> - does not depend on any complicated language changes (e.g. value objects);
> - simple to implement and optimize on any platform (including 32bit ones);

...I'd say it's not particularly necessary for the short-term, and it's 
definitely not sufficient for the long-term. We can and must do better for 
programmers than declare {lo, hi} as a realistic API for 64-bit integers. Value 
types are in JS's future.

> API considerations aside, though, I like the idea of bringing fast 64-bit 
> arithmetic to JS without waiting for value objects.

As I say, I could see doing the less wacky API for short-term, but I don't 
think it's vital.


es-discuss mailing list

Reply via email to