On 30 October 2013 18:47, Vyacheslav Egorov wrote:
> Some people find "global" state that this proposal introduces bad. I
> see two ways addressing this:
>
> - Returning {lo, hi} object.
>
> Pros: no global state, in combination with destructuring allows to
> write concise code, overhead can still
On Oct 30, 2013, at 1:56 PM, Luke Wagner 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 th
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 int
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
Some people find "global" state that this proposal introduces bad. I
see two ways addressing this:
- Returning {lo, hi} object.
Pros: no global state, in combination with destructuring allows to
write concise code, overhead can still be optimized away.
Cons: performance of polyfill is abysmal on
2013/10/30 Vyacheslav Egorov
> > Rationale being faster polyfilled execution
>
> The main reason for H being one shot is to allow optimizing compiler
> *elide* updating it in most cases to eliminate memory traffic.
>
Aaah. Thanks for pointing this out - I thought only of the polyfill
performance
2013/10/30 Vyacheslav Egorov
> 5. A one shot property Math.H is created that returns ch' on the first
> access and deletes itself.
>
Alternative step 5: Math.H is assigned ch'.
Rationale being faster polyfilled execution, in combination with a lack of
imagination from my side to come up with a
> Rationale being faster polyfilled execution
The main reason for H being one shot is to allow optimizing compiler
*elide* updating it in most cases to eliminate memory traffic.
After thinking about it a bit I propose the following alternative step 5:
Math.H is from the very beggining a non-conf
Hi,
There are algorithms that require 64-bit arithmetic, however currently
JavaScript does not provide any efficient way to perform it.
Similar to Math.imul which was added for the purposes of efficient
32-bit multiplication I propose extending Math object with a family of
operations Math.64 wher
9 matches
Mail list logo
