3 ms·

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 c

by 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.

by azakai 14y ago

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.