On 30 October 2013 18:47, Vyacheslav Egorov m...@mrale.ph 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
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.s64op
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
2013/10/30 Vyacheslav Egorov m...@mrale.ph
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
2013/10/30 Vyacheslav Egorov m...@mrale.ph
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
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
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
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
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?
9 matches
Mail list logo