4 ms·

Executable != useful though. This breeds a false sense of portability. If Firefox is the only browser that implements asm.js, it'll have about the same issues

Executable != useful though. This 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. 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.

masklinn 14y ago
> Executable != useful though. This breeds a false sense of portability. That's already a problem with many things web though, different browsers have different performance profiles already and things leading to smooth 60fps in one browser may not do so in an other one. The flip side for asmjs might be this: you manage 60fps on Chrome, Firefox is also at 60fps but uses less resources (since it's got special support) so you save wee birdies. That's cool.
azakai 14y ago
I agree that if that were the case, it would be a problem. However, I don't think we will see a 6x slowdown here. JavaScript engines are already very fast on compiled code, because they have already been optimizing for typed arrays and so forth for a while now. Google even added a compiled C++ benchmark to Octane, for example. In current benchmarks, asm.js gives you a speedup of anywhere from 1x (where normal JS optimizations already got us very close to native) to 6x. So 6x is the worst case, and there are plenty of cases in the middle. A 2x-3x difference is not big enough to make something a false sense of portability, the web has tolerated 2x-3x speed differences for a long time now, and these things also change a lot in terms of who is fastest, on what, and by what. Furthermore, I would not expect a 2x-3x difference to last very long, again, because browsers have been competing on performance of this type of code for a while now (Octane, etc.), and will continue to do so.
- cpeterso 14y ago
  Much of the discussion of asm.js focuses on Emscripten-compiled code. Would asm.js be useful for other tools that generate JS, such as CoffeeScript or Dart2JS?
  - azakai 14y ago
    Possibly yes, depending on the language. For CoffeeScript likely not, it is very close to normal JS, and lacks types. For Dart, I don't know enough about how the VM works. But in general, a language like Dart could work. For example, LuaJIT or PyPy could be ported, the C parts compiled into asm.js, and the JITs would need a new backend that emits asm.js instead of x86 or ARM. This could potentially make a language like Lua, Python, Dart, etc. very fast on the web. However, how feasible it is would depend on the VM architecture. I hope to work on this kind of stuff later this year.
    - cromwellian 14y ago
      The problem is, you'll end up porting those language's Garbage Collectors as well. I don't think it's that practical to compile GC'ed languages to asm.js until GC support is added. The GCs that are in Firefox and Chrome are very efficient low pause collectors, and IMHO, you really don't want to reimplement collector in JS, especially since you can't take advantage of OS/MMU features, and can't do multithreaded collection, etc. Also, if you consider something like the Java Virtual Machine, it's practical to make it work on NaCL, but JS doesn't support blocking/synchronous calls, and how earth would you make all of those synchronous APIs, and multithreaded APIs work in that context? asm.js is not isomorphic to NaCL in terms of feature set, but asm.js + something like OpenCL could probably work well for games.
      - azakai 14y ago
        GCing is a concern, yes. With the Binary Data API and some extensions, it might be possible down the road to have GC'd objects in asm.js compiled code. Definitely an interesting area to investigate. Multhreading is another concern, if you want shared state (with the JVM would need). It can't currently be done, but again, is worth thinking about and perhaps new web APIs could enable it some day.
egeozcan 14y ago
Well probably one could make the Dart Compiler output asm.js. Also, when you have an incompatible VM, you need to serve different content to different browsers. This, on the very least, eliminates that.

masklinn 14y ago

> Executable != useful though. This breeds a false sense of portability. That's already a problem with many things web though, different browsers have different performance profiles already and things leading to smooth 60fps in one browser may not do so in an other one. The flip side for asmjs might be this: you manage 60fps on Chrome, Firefox is also at 60fps but uses less resources (since it's got special support) so you save wee birdies. That's cool.

azakai 14y ago

I agree that if that were the case, it would be a problem. However, I don't think we will see a 6x slowdown here. JavaScript engines are already very fast on compiled code, because they have already been optimizing for typed arrays and so forth for a while now. Google even added a compiled C++ benchmark to Octane, for example. In current benchmarks, asm.js gives you a speedup of anywhere from 1x (where normal JS optimizations already got us very close to native) to 6x. So 6x is the worst case, and there are plenty of cases in the middle. A 2x-3x difference is not big enough to make something a false sense of portability, the web has tolerated 2x-3x speed differences for a long time now, and these things also change a lot in terms of who is fastest, on what, and by what. Furthermore, I would not expect a 2x-3x difference to last very long, again, because browsers have been competing on performance of this type of code for a while now (Octane, etc.), and will continue to do so.

cpeterso 14y ago
Much of the discussion of asm.js focuses on Emscripten-compiled code. Would asm.js be useful for other tools that generate JS, such as CoffeeScript or Dart2JS?
- azakai 14y ago
  Possibly yes, depending on the language. For CoffeeScript likely not, it is very close to normal JS, and lacks types. For Dart, I don't know enough about how the VM works. But in general, a language like Dart could work. For example, LuaJIT or PyPy could be ported, the C parts compiled into asm.js, and the JITs would need a new backend that emits asm.js instead of x86 or ARM. This could potentially make a language like Lua, Python, Dart, etc. very fast on the web. However, how feasible it is would depend on the VM architecture. I hope to work on this kind of stuff later this year.
  - cromwellian 14y ago
    The problem is, you'll end up porting those language's Garbage Collectors as well. I don't think it's that practical to compile GC'ed languages to asm.js until GC support is added. The GCs that are in Firefox and Chrome are very efficient low pause collectors, and IMHO, you really don't want to reimplement collector in JS, especially since you can't take advantage of OS/MMU features, and can't do multithreaded collection, etc. Also, if you consider something like the Java Virtual Machine, it's practical to make it work on NaCL, but JS doesn't support blocking/synchronous calls, and how earth would you make all of those synchronous APIs, and multithreaded APIs work in that context? asm.js is not isomorphic to NaCL in terms of feature set, but asm.js + something like OpenCL could probably work well for games.
    - azakai 14y ago
      GCing is a concern, yes. With the Binary Data API and some extensions, it might be possible down the road to have GC'd objects in asm.js compiled code. Definitely an interesting area to investigate. Multhreading is another concern, if you want shared state (with the JVM would need). It can't currently be done, but again, is worth thinking about and perhaps new web APIs could enable it some day.

egeozcan 14y ago

Well probably one could make the Dart Compiler output asm.js. Also, when you have an incompatible VM, you need to serve different content to different browsers. This, on the very least, eliminates that.