3 ms·

64 bit integers are one small example of something you can't do no matter how fast you make JavaScript.

apaprocki 13y ago
Value types (64-bit, DFP, etc) are possibly on the table for ES7. Brendan has a strawman he shows in talks. If you look at his JSConf.EU video he discusses it. edit: Video link http://www.youtube.com/watch?v=IXIkTrq3Rgg http://www.youtube.com/watch?v=IXIkTrq3Rgg
pcwalton 13y ago
JavaScript needs 64-bit integers no matter what; the Node folks have been clamoring for it for a long time. We need to add them. Same with SIMD. JavaScript is not some immutable thing. It needs enhancing, not replacing.
- deleted 13y ago
  [deleted]
v13inc 13y ago
That's not quite true -- it is entirely possible to write a 64-bit integer class entirely in Javascript, and have a JIT / ASM.js compiler recognize that and swap out a native version (See ecmascript_simd [1] which I believe was written with this idea in mind) [1] https://github.com/johnmccutchan/ecmascript_simd https://github.com/johnmccutchan/ecmascript_simd
- aboodman 13y ago
  Do you have any pointers to how value types can be implemented efficiently without adding type tags to the language? I can see how that would work in simple cases (say within one function), but it seems that there would be many cases where the vm cannot assume the type of a variable. I looked at the spec briefly (http://wiki.ecmascript.org/doku.php?id=strawman:value_objects#performance http://wiki.ecmascript.org/doku.php?id=strawman:value_object...), but it doesn't talk about the how.
  - kevingadd 13y ago
    Many JS implementations use type tags already. SpiderMonkey, for example - they call it 'nan-boxing'. See http://stackoverflow.com/questions/9435338/what-is-the-aim-of-js-canonicalize-nan-in-spidermonkey-engine http://stackoverflow.com/questions/9435338/what-is-the-aim-o...
    - aboodman 13y ago
      Sorry I meant type "tags" in the sense of modifying the language syntax to have required type annotations. I understand nan-boxing and similar techniques, but they seem to imply at least some runtime overhead to test the type of the value in some cases. Also, AFAIK, 64 bit integers cannot be represented with nan-boxing, as there are only 51 bits available for the payload.
      - kevingadd 13y ago
        That's correct, nan boxing doesn't help for 64-bit integers. On the other hand, Dart doesn't have required type annotations either and it has 64-bit ints, doesn't it? So it should be possible to introduce in JS. Runtime overhead is likely, but then when you're in the JIT sweet spot the types are all known so you get JITcode that doesn't check types.
        aboodman 13y ago
        I think that part of the value people see in things like NaCL is not having to rely on JIT magic to figure out when to optimize 64 bit math. You get direct control over what is going on. It may be true that in certain edge cases the JIT can actually out-perform clean native code, but people are willing to sacrifice that for direct control over what the machine does. GC is a related example of a place where VM designers told us not to worry ourselves, but it turns out that GC is inherently hard and you are going to pay for that convenience - either in performance or in memory. See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://sealedabstract.com/rants/why-mobile-web-apps-are-slow....

Value types (64-bit, DFP, etc) are possibly on the table for ES7. Brendan has a strawman he shows in talks. If you look at his JSConf.EU video he discusses it. edit: Video link http://www.youtube.com/watch?v=IXIkTrq3Rgg http://www.youtube.com/watch?v=IXIkTrq3Rgg

pcwalton 13y ago

JavaScript needs 64-bit integers no matter what; the Node folks have been clamoring for it for a long time. We need to add them. Same with SIMD. JavaScript is not some immutable thing. It needs enhancing, not replacing.

deleted 13y ago
[deleted]

v13inc 13y ago

That's not quite true -- it is entirely possible to write a 64-bit integer class entirely in Javascript, and have a JIT / ASM.js compiler recognize that and swap out a native version (See ecmascript_simd [1] which I believe was written with this idea in mind) [1] https://github.com/johnmccutchan/ecmascript_simd https://github.com/johnmccutchan/ecmascript_simd

aboodman 13y ago
Do you have any pointers to how value types can be implemented efficiently without adding type tags to the language? I can see how that would work in simple cases (say within one function), but it seems that there would be many cases where the vm cannot assume the type of a variable. I looked at the spec briefly (http://wiki.ecmascript.org/doku.php?id=strawman:value_objects#performance http://wiki.ecmascript.org/doku.php?id=strawman:value_object...), but it doesn't talk about the how.
- kevingadd 13y ago
  Many JS implementations use type tags already. SpiderMonkey, for example - they call it 'nan-boxing'. See http://stackoverflow.com/questions/9435338/what-is-the-aim-of-js-canonicalize-nan-in-spidermonkey-engine http://stackoverflow.com/questions/9435338/what-is-the-aim-o...
  - aboodman 13y ago
    Sorry I meant type "tags" in the sense of modifying the language syntax to have required type annotations. I understand nan-boxing and similar techniques, but they seem to imply at least some runtime overhead to test the type of the value in some cases. Also, AFAIK, 64 bit integers cannot be represented with nan-boxing, as there are only 51 bits available for the payload.
    - kevingadd 13y ago
      That's correct, nan boxing doesn't help for 64-bit integers. On the other hand, Dart doesn't have required type annotations either and it has 64-bit ints, doesn't it? So it should be possible to introduce in JS. Runtime overhead is likely, but then when you're in the JIT sweet spot the types are all known so you get JITcode that doesn't check types.
      - aboodman 13y ago
        I think that part of the value people see in things like NaCL is not having to rely on JIT magic to figure out when to optimize 64 bit math. You get direct control over what is going on. It may be true that in certain edge cases the JIT can actually out-perform clean native code, but people are willing to sacrifice that for direct control over what the machine does. GC is a related example of a place where VM designers told us not to worry ourselves, but it turns out that GC is inherently hard and you are going to pay for that convenience - either in performance or in memory. See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://sealedabstract.com/rants/why-mobile-web-apps-are-slow....