Yes, all API variants I have proposed should result in the equivalent
performance, to the best of my knowledge.

I would even say that {lo, hi} one is easier on VMs for two reasons:

- VMs tend to have some sort of escape analysis / allocation sinking
and they can incorporate { lo, hi } support into this pass;

- If VM desires to allocate { lo, hi } value to a single register it
might be easier to do that when values are explicitly grouped, VM does
not have to rediscover pairing --- it is already there.

You also correctly reasoned that I proposed magic property API for the
purposes of faster polyfilling.

So given the choice between { lo, hi } and magical property API if I
would prefer { lo, hi } iff I ignore polyfill performance.

> The other main use case I can think of is large compiled C++ codebases

I saw crypto libraries (e.g. NaCl) heavily relying on 64bit arithmetic.

> Are there any other use cases you have in mind that really demand high polyfill performance?

I am interested in the whole number hierarchy actually (int32 - int64
- bigint). But I have no clear idea what to do here.

One possibility would be to allow passing type arrays alongside with
primitive numbers into something Math.big<op>. But this is pretty ugly
and probably also results in abysmal polyfill performance.


--
Vyacheslav Egorov


On Wed, Oct 30, 2013 at 9:56 PM, Luke Wagner <luke at 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.
>
> 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.
>
> Are there any other use cases you have in mind that really demand high polyfill performance?
>
> API considerations aside, though, I like the idea of bringing fast 64-bit arithmetic to JS without waiting for value objects.
>
> Cheers,
> Luke
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Yes, all API variants I have proposed should result in the equivalent performance, to the best of my knowledge.

I would even say that {lo, hi} one is easier on VMs for two reasons:

- VMs tend to have some sort of escape analysis / allocation sinking and they can incorporate { lo, hi } support into this pass;
- If VM desires to allocate { lo, hi } value to a single register it might be easier to do that when values are explicitly grouped, VM does not have to rediscover pairing --- it is already there.

You also correctly reasoned that I proposed magic property API for the
purposes of faster polyfilling.

So given the choice between { lo, hi } and magical property API if I
would prefer { lo, hi } iff I ignore polyfill performance.

> The other main use case I can think of is large compiled C++ codebases

I saw crypto libraries (e.g. NaCl) heavily relying on 64bit arithmetic.

> Are there any other use cases you have in mind that really demand high polyfill performance?

I am interested in the whole number hierarchy actually (int32 - int64 - bigint). But I have no clear idea what to do here.

One possibility would be to allow passing type arrays alongside with primitive numbers into something `Math.big<op>`. But this is pretty ugly and probably also results in abysmal polyfill performance.