proposal for efficient 64-bit arithmetic without value objects

Vyacheslav Egorov me at mrale.ph
Wed Oct 30 10:47:56 PDT 2013


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 bad and moderately good
VMs, requires allocation sinking pass to optimize away object
allocation.

- Make H property of the respective operation (e.g. u64mul updates its
own property H)

Pros: easy to implement, good perf on bad VMs
Cons: still kinda global state

- Math.<s>64<op> can become Math.createOperator(<s>64, <op>) that
returns function with H property:

var add = Math.createOperator("u64", "add");
var dl = add(add(al, ah, bl, bh), add.H, cl, ch);
var dh = add.H;

Pros: no global state, relatively good performance on the non advanced
VMs, can be actually extended(!) e.g. SIMD operations can be exposed
as Math.createOperator("simd128", "add")

--
Vyacheslav Egorov


On Wed, Oct 30, 2013 at 5:46 PM, Olov Lassus <olov.lassus at gmail.com> wrote:
> 2013/10/30 Vyacheslav Egorov <me at 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
> performance so I neglected this key aspect of your proposal.
>
>>
>> After thinking about it a bit I propose the following alternative step 5:
>>
>> Math.H is from the very beggining a non-configurable non-writable
>> accessor property with a getter that returns hidden inner value and
>> always zeros inner value.
>
>
> +1 (for now) :)
>
> /Olov
>


More information about the es-discuss mailing list