3 ms·

It's not an optimization for asm.js if you ignore the "use asm". It's just javascript then.

by kingkilr 13y ago

Ygg2 13y ago
Which is what asm.js is mostly. Subset of javascript.
- justinschuh 13y ago
  No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.
  - pcwalton 13y ago
    Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats. The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.
    - justinschuh 13y ago
      My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript." What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?
      - pcwalton 13y ago
        "use asm" is not a keyword. It can be ignored, as V8 does. This is possible because asm.js is JavaScript as defined by ECMA-262. It executes according to the semantics specified in that document. I don't really want this to turn into a back-and-forth, but it's unfortunate that this has devolved into outright accusations of dishonesty.
        justinschuh 13y ago
        Note that I framed it as "not exactly honest" rather than saying it's an overt lie. Because I don't consider it an overt lie, but it's hard not to read it as a bit equivocal to claim that asm.js as just JavaScript. And really, I'm far more concerned with the future plans, particularly with regard to things like multi-threading APIs. I don't see how those can be incorporated in a way that supports asm.js as an easy target for existing code while not causing it to diverge from JavaScript as used in the browser.
        dherman 13y ago
        Yes, threading is definitely the main challenge for asm.js. I'm not as pessimistic as you about it, though. :)
        justinschuh 13y ago
        To be clear, I really do think those of you working on asm.js have the best of intentions and really want to make something that works for the Web. However, I expect that supporting existing codebases and commonly used APIs is going to mean compromises. They'll start small and polyfills will work well enough, but I just don't see how asm.js doesn't eventually diverge in significant ways from normal JavaScript, or end up introducing special purpose hacks. Maybe I'm wrong, but I don't see my position as unrealistic.
      - dherman 13y ago
        > My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.
coldtea 13y ago
asm.js is a subset of javascript. Nothing more. If you implement the optimisations without needing the "use asm" then you just have the same benefits for non asm tagged code -- and all the benefits of asm. The "use asm" is totally optional functionality wise.

It's not an optimization for asm.js if you ignore the "use asm". It's just javascript then.

Ygg2 13y ago

Which is what asm.js is mostly. Subset of javascript.

justinschuh 13y ago
No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.
- pcwalton 13y ago
  Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats. The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.
  - justinschuh 13y ago
    My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript." What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?
    - pcwalton 13y ago
      "use asm" is not a keyword. It can be ignored, as V8 does. This is possible because asm.js is JavaScript as defined by ECMA-262. It executes according to the semantics specified in that document. I don't really want this to turn into a back-and-forth, but it's unfortunate that this has devolved into outright accusations of dishonesty.
      - justinschuh 13y ago
        Note that I framed it as "not exactly honest" rather than saying it's an overt lie. Because I don't consider it an overt lie, but it's hard not to read it as a bit equivocal to claim that asm.js as just JavaScript. And really, I'm far more concerned with the future plans, particularly with regard to things like multi-threading APIs. I don't see how those can be incorporated in a way that supports asm.js as an easy target for existing code while not causing it to diverge from JavaScript as used in the browser.
        dherman 13y ago
        Yes, threading is definitely the main challenge for asm.js. I'm not as pessimistic as you about it, though. :)
        justinschuh 13y ago
        To be clear, I really do think those of you working on asm.js have the best of intentions and really want to make something that works for the Web. However, I expect that supporting existing codebases and commonly used APIs is going to mean compromises. They'll start small and polyfills will work well enough, but I just don't see how asm.js doesn't eventually diverge in significant ways from normal JavaScript, or end up introducing special purpose hacks. Maybe I'm wrong, but I don't see my position as unrealistic.
    - dherman 13y ago
      > My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.

coldtea 13y ago

asm.js is a subset of javascript. Nothing more. If you implement the optimisations without needing the "use asm" then you just have the same benefits for non asm tagged code -- and all the benefits of asm. The "use asm" is totally optional functionality wise.