4 ms·

Even though it's using JavaScript as a kind of bytecode, it is just JavaScript / HTML5 (and some CSS, but that's pretty anedoctical I guess). Asm.js is a subset

by elisee 13y ago

Even though it's using JavaScript as a kind of bytecode, it is just JavaScript / HTML5 (and some CSS, but that's pretty anedoctical I guess). Asm.js is a subset of JavaScript. As soon as Chrome fixes the crash, it'll run in a browser that supports just HTML5 (for presenting the page / the DOM / the canvas) and JavaScript with no special asm.js optimizations, and we'll have to see how fast/slow it is then. To correct your analogy: it'd be like using a subset of C# as the bytecode rather than a language. It's still actual C#, it's not just .NET bytecode, but it's being used differently.

CmonNoReg 13y ago
I wouldn't write a large-scale game/engine in byte code. It is effectively a C++ demo.
just2n 13y ago
I understand that. Take a read of this: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html. I have a lot of respect for Egorov, and I agree with his views on this matter quite entirely. The sole benefit of embedding a bytecode in a language is that you get the side effect that it can run anywhere that language runs. But in general, this implies performance penalties, especially when the language is relatively slow to begin with. But in this case, this demo is made usable (ie: the impressive part) by writing a compiler specifically for the bytecode itself. So it works well in spite of the fact that it's a bytecode embedded in JS, not because of it. The really cool things about this demo are precisely 2 things: 1. asm.js makes running C++ code that would render to OpenGL in the browser a possibility, and with relatively good performance. Kudos to Mozilla. 2. It runs on browsers that don't know about asm.js, but it's effectively an emulated machine, and it's slow. I just take issue with calling this an example of what JavaScript/HTML5 can do. I think seeing an application written in JS using WebGL or Canvas as something much more impressive, and there are Q3 renderers that are natively JS that run with amazing performance in the browser. This is just dressing up the fact that turing completeness is a thing and calling attention to it. The real thing to get from this demo is that there are enormous benefits to having a bytecode for the web over trying to optimize a fully dynamic language like JS. I feel like that is relatively lost by the title.
- azakai 13y ago
  > 1. asm.js makes running C++ code that would render to OpenGL in the browser a possibility, and with relatively good performance. Kudos to Mozilla. > 2. It runs on browsers that don't know about asm.js, but it's effectively an emulated machine, and it's slow. Do you have benchmark numbers to support that? In my experience, asm.js code is quite fast even without special asm.js optimizations. It depends on the benchmark obviously, but look at http://kripken.github.io/mloc_emscripten_talk/#/27 http://kripken.github.io/mloc_emscripten_talk/#/27 Many of those benchmarks are very fast in browsers without special asm.js optimizations. All they need to do to be fast on asm.js code is to optimize typed array operations and basic math, and those are things browsers have been doing for a long time. Google even added a Mandreel benchmark to Octane for this reason. Emscripten and Mandreel output, with or without asm.js, tends to be quite fast, generally faster than handwritten code. asm.js is often faster than that, because it's easier to optimize, even without special optimizations for it. Those special optimizations can help even more, but they are not necessary for it to run, nor are things "slow/emulated" without them.
  - Hnefi 13y ago
    That link is misleading in the context you present it. Those are microbenchmarks, which a JIT can optimize relatively well. But if you look at the very next slide at http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 you will see that for a larger application, non-optimized asm.js performs abysmally, as does JS in general. A performance penalty of ~1000% of native is what you should expect for a nontrivial JS application, and asm.js does not do much (if anything) to alleviate that unless you run odinmonkey.
    - azakai 13y ago
      I was purposefully linking to that slide + the one after it. Yes, there is a factor of around 4x slowdown between asm.js optimizations and without them, on the next slide. But even 4x slower than asm.js is quite fast, it's enough to run the Epic Citadel demo for example (try it on a version of firefox without those optimizations, like stable release - as others reported in comments, it runs ok). A lot of the work in Epic Citadel is on the GPU anyhow, say it's about half, so the difference is then only something like 2x. 2x is not that much, we have similar differences on the web anyhow because of CPU differences, JIT differences, etc. That's within the expected range of variance. Also, asm.js code is faster even without special optimizations compared to handwritten JS (see for example http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_Runtime_Performance http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_R... and http://blog.j15r.com/blog/2013/04/25/Box2d_Revisited http://blog.j15r.com/blog/2013/04/25/Box2d_Revisited ). So even without those optimizations it is worthwhile.

by elisee 13y ago

CmonNoReg 13y ago

I wouldn't write a large-scale game/engine in byte code. It is effectively a C++ demo.

just2n 13y ago

I understand that. Take a read of this: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html. I have a lot of respect for Egorov, and I agree with his views on this matter quite entirely. The sole benefit of embedding a bytecode in a language is that you get the side effect that it can run anywhere that language runs. But in general, this implies performance penalties, especially when the language is relatively slow to begin with. But in this case, this demo is made usable (ie: the impressive part) by writing a compiler specifically for the bytecode itself. So it works well in spite of the fact that it's a bytecode embedded in JS, not because of it. The really cool things about this demo are precisely 2 things: 1. asm.js makes running C++ code that would render to OpenGL in the browser a possibility, and with relatively good performance. Kudos to Mozilla. 2. It runs on browsers that don't know about asm.js, but it's effectively an emulated machine, and it's slow. I just take issue with calling this an example of what JavaScript/HTML5 can do. I think seeing an application written in JS using WebGL or Canvas as something much more impressive, and there are Q3 renderers that are natively JS that run with amazing performance in the browser. This is just dressing up the fact that turing completeness is a thing and calling attention to it. The real thing to get from this demo is that there are enormous benefits to having a bytecode for the web over trying to optimize a fully dynamic language like JS. I feel like that is relatively lost by the title.

azakai 13y ago
> 1. asm.js makes running C++ code that would render to OpenGL in the browser a possibility, and with relatively good performance. Kudos to Mozilla. > 2. It runs on browsers that don't know about asm.js, but it's effectively an emulated machine, and it's slow. Do you have benchmark numbers to support that? In my experience, asm.js code is quite fast even without special asm.js optimizations. It depends on the benchmark obviously, but look at http://kripken.github.io/mloc_emscripten_talk/#/27 http://kripken.github.io/mloc_emscripten_talk/#/27 Many of those benchmarks are very fast in browsers without special asm.js optimizations. All they need to do to be fast on asm.js code is to optimize typed array operations and basic math, and those are things browsers have been doing for a long time. Google even added a Mandreel benchmark to Octane for this reason. Emscripten and Mandreel output, with or without asm.js, tends to be quite fast, generally faster than handwritten code. asm.js is often faster than that, because it's easier to optimize, even without special optimizations for it. Those special optimizations can help even more, but they are not necessary for it to run, nor are things "slow/emulated" without them.
- Hnefi 13y ago
  That link is misleading in the context you present it. Those are microbenchmarks, which a JIT can optimize relatively well. But if you look at the very next slide at http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 you will see that for a larger application, non-optimized asm.js performs abysmally, as does JS in general. A performance penalty of ~1000% of native is what you should expect for a nontrivial JS application, and asm.js does not do much (if anything) to alleviate that unless you run odinmonkey.
  - azakai 13y ago
    I was purposefully linking to that slide + the one after it. Yes, there is a factor of around 4x slowdown between asm.js optimizations and without them, on the next slide. But even 4x slower than asm.js is quite fast, it's enough to run the Epic Citadel demo for example (try it on a version of firefox without those optimizations, like stable release - as others reported in comments, it runs ok). A lot of the work in Epic Citadel is on the GPU anyhow, say it's about half, so the difference is then only something like 2x. 2x is not that much, we have similar differences on the web anyhow because of CPU differences, JIT differences, etc. That's within the expected range of variance. Also, asm.js code is faster even without special optimizations compared to handwritten JS (see for example http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_Runtime_Performance http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_R... and http://blog.j15r.com/blog/2013/04/25/Box2d_Revisited http://blog.j15r.com/blog/2013/04/25/Box2d_Revisited ). So even without those optimizations it is worthwhile.