Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-31 Thread Andreas Rossberg
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread David Herman
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread 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. After thinking about it a bit I propose the following alternative step 5: Math.H is from the very beggining a non-conf