Hi Fabrice,
Thanks for the proposal, I ran it by TC39 yesterday and it advanced to
stage 0. This means work getting to stage 1, per:
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit
The committee liked it not only for emulating int64 and uint64 more
On Wed, Sep 24, 2014 at 5:37 PM, Brendan Eich bren...@mozilla.org wrote:
Hi Fabrice,
Thanks for the proposal, I ran it by TC39 yesterday and it advanced to
stage 0. This means work getting to stage 1, per:
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaV
Hi Fabrice,
The main reason why I was proposing (hi, lo)-pair based API instead of
lower version is to
a) avoid necessity writing low-level looking code in the high-level
language which is JS;
b) avoid pattern matching in the JS code to recognize construction
built out of low-level 32-bit
Note: my proposal is not limited to 64 bit operations. It can be used to
efficiently implement arbitrary precision arithmetic.
64 bit integer division and remainder are less critical than the other
operations because they are seldom used and slow anyway. Moreover, it is
more difficult to
Note: my proposal is not limited to 64 bit operations. It can be used to
efficiently implement arbitrary precision arithmetic.
True, it is easier to arrive to the efficient and clear code with lowered
representation. With (lo, hi)-result API compiler will have to figure more
things out on it's
Hi all,
Regarding 64 bit arithmetic, there is a simpler solution compared to
what was proposed in [1]. It is already possible to get the low 32 bit
part of the 64 bit operations for addition, subtraction and
multiplication. So it is enough to add a few more functions to get the
high 32 bit
I like this a lot.
It looks like it will have a fairly mellow performance cliff in cases where VM
optimizations fail for whatever reason, since even in a lower-tier compiler
incapable of sophisticated optimizations all you really have to do is make sure
that these new math function calls
Latest news on div AFAIK:
https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32221
On Tue, Jul 8, 2014 at 10:45 AM, Filip Pizlo fpi...@apple.com wrote:
I like this a lot.
It looks like it will have a fairly mellow performance cliff in cases
where VM optimizations fail for
That’s unrelated, since that discussion deals with integer division for the
domain of integers that is representable using ES numbers (i.e. IEEE doubles).
This discussion, and my question about division, is in regards to 64-bit
arithmetic.
64-bit integers do not fit into ES numbers, and so
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?
18 matches
Mail list logo
