4 ms·

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 run

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?
  - ash 14y ago
    It's not about overloading. JavaScript language doesn't have integers, only floats. JS engine has to use floating point add for (x + y). It's slower that integer add. But (x + y) | 0 truncates any float values that could theoretically come up, allowing JS engine to safely optimize it by using integer add directly.
Joeri 14y ago
The dart people should make dartjs generate asm.js code.
- ahoge 14y ago
  asm.js is currently only a usable target if you use C. You also can't compile JS to asm.js, for example. You get C-like performance by writing C.
  - azakai 14y ago
    That is true, but remember that VMs for languages like Python, Lua, etc. are written in C. That means you can compile them to asm.js. There are demos of this (using emscripten, not asm.js) from a while back. If you ported a VM with a JIT, and added an asm.js backend for that JIT, it could be a very fast way to run basically any language in asm.js.
cromwellian 14y ago
Dart has been developed in the open as well. It's not even released in Chrome yet, it's been fully in the open for 2 years, which is most of its existence and has undergone massive revision since the original seeding of the project based on community contributes. Yes, my comment was snarky. No matter how you slice it, adding a pragma, and requiring code to be written in an idiomatic format to gain maximum advantage by a conforming VM implementation is essentially introducing a new set of semantics to the VM. The fact that you can sneak it into the existing grammar (x|0) instead of needing to extend the grammar (int x), is a neat trick. I fully support what asm.js is doing, I don't have any objections to it, and once the Garbage Collection support happens, I will look very hard at making GWT support it as an output format (primarily to support PlayN). But I wish Mozilla would stop peppering everyone of their press releases with a thinly veiled snipe at competitors.

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?
- ash 14y ago
  It's not about overloading. JavaScript language doesn't have integers, only floats. JS engine has to use floating point add for (x + y). It's slower that integer add. But (x + y) | 0 truncates any float values that could theoretically come up, allowing JS engine to safely optimize it by using integer add directly.

Joeri 14y ago

The dart people should make dartjs generate asm.js code.

ahoge 14y ago
asm.js is currently only a usable target if you use C. You also can't compile JS to asm.js, for example. You get C-like performance by writing C.
- azakai 14y ago
  That is true, but remember that VMs for languages like Python, Lua, etc. are written in C. That means you can compile them to asm.js. There are demos of this (using emscripten, not asm.js) from a while back. If you ported a VM with a JIT, and added an asm.js backend for that JIT, it could be a very fast way to run basically any language in asm.js.

cromwellian 14y ago

Dart has been developed in the open as well. It's not even released in Chrome yet, it's been fully in the open for 2 years, which is most of its existence and has undergone massive revision since the original seeding of the project based on community contributes. Yes, my comment was snarky. No matter how you slice it, adding a pragma, and requiring code to be written in an idiomatic format to gain maximum advantage by a conforming VM implementation is essentially introducing a new set of semantics to the VM. The fact that you can sneak it into the existing grammar (x|0) instead of needing to extend the grammar (int x), is a neat trick. I fully support what asm.js is doing, I don't have any objections to it, and once the Garbage Collection support happens, I will look very hard at making GWT support it as an output format (primarily to support PlayN). But I wish Mozilla would stop peppering everyone of their press releases with a thinly veiled snipe at competitors.