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

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

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

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

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

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

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

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 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

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 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?