5 ms·

Hoisting my comment up: Executable != useful. Saying asm.js runs in VMs that have no special support for it breeds a false sense of portability. If Firefox is

Hoisting my comment up: Executable != useful. Saying asm.js runs in VMs that have no special support for it breeds a false sense of portability. If Firefox is the only browser that implements asm.js, it'll have about the same issues as Dart or NaCL. That is, Dart also compiles to JS, but if Dart2JS were 6x slower on Firefox than Chrome, no one would be cheering, and in fact, this is a complaint Mozilla themselves raised in the beginning (that if DartVM has an enormous performance advantage compared to Dart2JS it would make other browsers look bad and fragment things) If I'm writing a game in C and compiling it to asm.js, and it's gonna run 6x slower everywhere else, I'm effectively developing it for Firefox only no differently than if I had compiled C to NaCL/PNaCL. For this to be effective, it has to be cross browser. At least, Mozilla and WebKit/Chrome. (honestly, without WebGL support, I don't think it helps IE with games anyway)

kevingadd 14y ago
I don't think you understand asm.js. It's cross browser. If it happens to run slowly in v8 that's just because v8 is poor at optimizing JS that makes heavy use of typed arrays (which is already the case in some scenarios, demonstrated by Chrome's performance being inferior to Firefox's on many non-asm.js benchmarks).
- cromwellian 14y ago
  Did you fail to understand my point? Dart is cross browser too. You write a Dart app, it runs in the DartVM on Chrome, and runs as JS on Firefox. If Firefox runs it slowly, it's because Firefox is worse at recognizing the patterns of transpiled Dart code, right? I could define my own spec, "dartjs.js" which has specific style of writing JS that a VM could be tuned to recognize. Same issue. I'm not attacking ASM.JS here, I'm just pointing out that if it isn't supported by other browsers, no one seeking high performance can depend on its portability in that regard. None of this makes any difference to a developer who is trying to ship a game, he has to deal with the world as it is. And if the world is Firefox has asm.js, and Chrome has NaCL, then they will write their games in C/C++, and use Emscripten+Asm.js for Firefox, and NaCL for Chrome, so NaCL still won't go away. The point is, rather than just dumping a new spec and VM module on the community, it has to be a cooperate effort so that there's a stable platform to target that isn't a pathologically bad performer elsewhere.
  - kevingadd 14y ago
    When you say 'dumping a new spec and VM on the community' are you referring to NaCL and Dart? Because asm.js isn't a new vm, and it already works in other browsers, like I said. If a particular device can only run Java applications in an interpreter, that doesn't mean Java doesn't work on that device, or that Java isn't cross-platform. It just means the vendor hasn't done the work to implement a high-performance JIT (or can't). In this case, nothing is stopping other vendors from providing high performance for ASM.js applications: The spec is being developed in the open with involvement from interested parties - not by a bunch of stakeholders at one private company - and it produces JS that works in any JS runtime. You could, if you chose, simply make ASM.js applications faster by making all JS applications faster; many of the same optimizations apply. Any suggestion of 'support' is entirely missing the point: It's Just JavaScript. REALLY. That's it. The point is that it's JavaScript that conforms to rules (enforced on the ASM.js compiler, not the JS runtime) that enable runtimes to apply additional optimizations. Some of these rules can (and probably already do) enable a runtime to apply additional optimizations even if it is unaware of asm.js. The most obvious example of this is the 'n | 0' pattern. When you're doing some integer arithmetic in JS, you can and probably will write this: var z = x * y; But an ASM.js compliant compiler will, if x and y are both integral, write something like this [1]: var z = (x * y) | 0; These both achieve the same result, but the latter provides more information to any JS runtime - not just an ASM.js one - that enables more optimizations. And in fact if you benchmark properly right now, the | 0 hint produces better performance for integer arithmetic in builds of Firefox that do not have asm.js. [1] Technically I think it might actually spit out a call to Math.imul, and not an actual use of the mul operator. But I digress.
    - iSnow 14y ago
      >These both achieve the same result, but the latter provides more information to any JS runtime - not just an ASM.js one - that enables more optimizations. And in fact if you benchmark properly right now, the | 0 hint produces better performance for integer arithmetic Could you elaborate please? I am not a JS expert, so I am confused why ORing with an int would help in a multiplication. I'd understand if it was (x + y) | 0, but the star operator is - to the best of my knowledge - not overloaded in JS, so the JS compiler can already assume x and y to be numeric. What kind of optimization does it trigger in your example?
azakai 14y ago
Not sure what the point of hoisting/copying your comment up is? Now all of our replies must be duplicated as well? Original replies are under the original post, https://news.ycombinator.com/item?id=5419154 https://news.ycombinator.com/item?id=5419154
- cromwellian 14y ago
  I should have deleted the original, my bad.
cliffbean 14y ago
I agree with your point; while functionality portability is important, we really want performance portability too. A big challenge we seem to have with any of the available options is convincing all the major browser makers to agree on something. And even though asm.js won't have perfect performance portability at first, it looks like it should be a much easier sell to browser vendors than Dart or NaCl were. With asm.js, browser vendors won't need to add a new VM. They'll just need new optimizations within their existing VM. There's no new security model to understand, no API from someone else's browser to emulate, and no large set of features which will be redundant between VMs. And, asm.js has a lot lower risk of becoming a legacy nightmare if it doesn't catch on. Or if the specification changes. It's just optimizations, so there's room to maneuver when customers with old code demand that you support them forever.
- cromwellian 14y ago
  On security, I'm not sure I agree. Part of achieving optimizations is making enough assumptions to perform them, and that leaves you open to holes in your validator. If validation isn't correct, then you could potentially trigger the optimizer to create bad code that would be exploitable. We've basically moved to Java bytecode verification to asm.js verification. This is just speculation, but I'm actually concerned about the potential security implications.
- bradleyjg 14y ago
  Browser vendors is a bit abstract when you are talking about a group of four, two of which have horses in the race. In theory there were good reasons to think browser vendors would support ogg, in practice MS and Apple showed zero interest.

kevingadd 14y ago

I don't think you understand asm.js. It's cross browser. If it happens to run slowly in v8 that's just because v8 is poor at optimizing JS that makes heavy use of typed arrays (which is already the case in some scenarios, demonstrated by Chrome's performance being inferior to Firefox's on many non-asm.js benchmarks).

cromwellian 14y ago
Did you fail to understand my point? Dart is cross browser too. You write a Dart app, it runs in the DartVM on Chrome, and runs as JS on Firefox. If Firefox runs it slowly, it's because Firefox is worse at recognizing the patterns of transpiled Dart code, right? I could define my own spec, "dartjs.js" which has specific style of writing JS that a VM could be tuned to recognize. Same issue. I'm not attacking ASM.JS here, I'm just pointing out that if it isn't supported by other browsers, no one seeking high performance can depend on its portability in that regard. None of this makes any difference to a developer who is trying to ship a game, he has to deal with the world as it is. And if the world is Firefox has asm.js, and Chrome has NaCL, then they will write their games in C/C++, and use Emscripten+Asm.js for Firefox, and NaCL for Chrome, so NaCL still won't go away. The point is, rather than just dumping a new spec and VM module on the community, it has to be a cooperate effort so that there's a stable platform to target that isn't a pathologically bad performer elsewhere.
- kevingadd 14y ago
  When you say 'dumping a new spec and VM on the community' are you referring to NaCL and Dart? Because asm.js isn't a new vm, and it already works in other browsers, like I said. If a particular device can only run Java applications in an interpreter, that doesn't mean Java doesn't work on that device, or that Java isn't cross-platform. It just means the vendor hasn't done the work to implement a high-performance JIT (or can't). In this case, nothing is stopping other vendors from providing high performance for ASM.js applications: The spec is being developed in the open with involvement from interested parties - not by a bunch of stakeholders at one private company - and it produces JS that works in any JS runtime. You could, if you chose, simply make ASM.js applications faster by making all JS applications faster; many of the same optimizations apply. Any suggestion of 'support' is entirely missing the point: It's Just JavaScript. REALLY. That's it. The point is that it's JavaScript that conforms to rules (enforced on the ASM.js compiler, not the JS runtime) that enable runtimes to apply additional optimizations. Some of these rules can (and probably already do) enable a runtime to apply additional optimizations even if it is unaware of asm.js. The most obvious example of this is the 'n | 0' pattern. When you're doing some integer arithmetic in JS, you can and probably will write this: var z = x * y; But an ASM.js compliant compiler will, if x and y are both integral, write something like this [1]: var z = (x * y) | 0; These both achieve the same result, but the latter provides more information to any JS runtime - not just an ASM.js one - that enables more optimizations. And in fact if you benchmark properly right now, the | 0 hint produces better performance for integer arithmetic in builds of Firefox that do not have asm.js. [1] Technically I think it might actually spit out a call to Math.imul, and not an actual use of the mul operator. But I digress.
  - iSnow 14y ago
    >These both achieve the same result, but the latter provides more information to any JS runtime - not just an ASM.js one - that enables more optimizations. And in fact if you benchmark properly right now, the | 0 hint produces better performance for integer arithmetic Could you elaborate please? I am not a JS expert, so I am confused why ORing with an int would help in a multiplication. I'd understand if it was (x + y) | 0, but the star operator is - to the best of my knowledge - not overloaded in JS, so the JS compiler can already assume x and y to be numeric. What kind of optimization does it trigger in your example?

azakai 14y ago

Not sure what the point of hoisting/copying your comment up is? Now all of our replies must be duplicated as well? Original replies are under the original post, https://news.ycombinator.com/item?id=5419154 https://news.ycombinator.com/item?id=5419154

cromwellian 14y ago
I should have deleted the original, my bad.

cliffbean 14y ago

I agree with your point; while functionality portability is important, we really want performance portability too. A big challenge we seem to have with any of the available options is convincing all the major browser makers to agree on something. And even though asm.js won't have perfect performance portability at first, it looks like it should be a much easier sell to browser vendors than Dart or NaCl were. With asm.js, browser vendors won't need to add a new VM. They'll just need new optimizations within their existing VM. There's no new security model to understand, no API from someone else's browser to emulate, and no large set of features which will be redundant between VMs. And, asm.js has a lot lower risk of becoming a legacy nightmare if it doesn't catch on. Or if the specification changes. It's just optimizations, so there's room to maneuver when customers with old code demand that you support them forever.

cromwellian 14y ago
On security, I'm not sure I agree. Part of achieving optimizations is making enough assumptions to perform them, and that leaves you open to holes in your validator. If validation isn't correct, then you could potentially trigger the optimizer to create bad code that would be exploitable. We've basically moved to Java bytecode verification to asm.js verification. This is just speculation, but I'm actually concerned about the potential security implications.
bradleyjg 14y ago
Browser vendors is a bit abstract when you are talking about a group of four, two of which have horses in the race. In theory there were good reasons to think browser vendors would support ogg, in practice MS and Apple showed zero interest.