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 <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.
>
> 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
