proposal for efficient 64-bit arithmetic without value objects

David Herman dherman at
Wed Oct 30 15:17:13 PDT 2013

On Oct 30, 2013, at 1:56 PM, Luke Wagner <luke at> 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.


More information about the es-discuss mailing list