6 ms·

Asm.js performance improvements in the latest version of Firefox

162 points by matt42 12y ago

erichurkman 12y ago
That asm.js demo of Angry Bots [1] is damn slick. In Chrome (2013 macbook air) it's a bit choppy, but on Firefox 30 beta it's very smooth. [1] http://beta.unity3d.com/jonas/AngryBots/ http://beta.unity3d.com/jonas/AngryBots/
- camus2 12y ago
  works well on FireFox even with an old computer,but yeah it's a catastrophy on Chrome or IE.Good for Firefox that could become the Gaming Browser. Bad for us devs that will have to learn C++ to get good perfs out of game,because you cant write asm.js by end.
  - Ygg2 12y ago
    Eh, it's possible to write asm.js just much harder than regular JavaScript. Keep in mind Operating systems were written in assembly, asm.js is not as bad as assembly in some regards.
    - TheZenPsycho 12y ago
      There are constraints to asm.js that are restrictively difficult for a human to maintain. If your code doesn't pass the validator it runs as normal JS.
    - jevinskie 12y ago
      LLJS targeting asm.js may help but it still looks like an early effort. http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available- http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available... https://github.com/jlongster/LLJS https://github.com/jlongster/LLJS
    - camus2 12y ago
      I'm not writing an operating system.The point is you cant get these perfs with using regular javascript.ASM.js is not regular javascript,since it's a subset.
      - Ygg2 12y ago
        No, but this operating system is the example of most performant, least resource hungry application I can think off. If you need performance you don't write C, you write assembly. Same with asm.js.
        pjc50 12y ago
        You try to avoid writing in assembly unless you absolutely have to, because it's a big maintenance pain and unless all your assumptions are correct it may not be as fast as the compiler. It's not worth bothering with unless you're vectorising or want to use some other instructions that are not normally emitted (e.g. ARM add-with-saturation).
        Ygg2 12y ago
        Yeah, but assembly generally isn't portable (x86 assembly is different than ARM assembly, etc.), that's what makes it biggest pain IIRC. Asm.js on the other hand, is portable and just that makes it way better than any regular assembly. Also it seems better looking than regular assembly (no registers as such, no jumps, etc.). It's a huge step back compared to plain JS, but it's not that impossible to write in.
  - k__ 12y ago
    Works "okayish" in Chrome for me.
- bjz_ 12y ago
  I was really surprised to see it barely using only a fraction of my CPU on my MBP in Aurora (was expecting to see it max out one of my cores). Very cool stuff.
jffry 12y ago
together with all the other work on optimizing asm.js, allows it to run at around 1.5x slower than the speed of the same C/C++ when compiled natively Running at 67% of native speed, and backwards compatible with all non ASM.js browsers? That's pretty great!
- hippich 12y ago
  I am working on a project based on asm.js technology. From my experience very limited and simple asm.js code might be compatible with "all non asm.js browsers". In particular I found IE9 wouldn't work with some compiled code. IE10 so far so good (but slow of course.)
  - nnethercote 12y ago
    asm.js relies on typed arrays, and IE9 doesn't support them. So I'd be surprised if IE9 was able to handle any asm.js code.
    - azakai 12y ago
      Emscripten can emit code without typed arrays. It's fairly slow but does work in IE9.
      - nnethercote 12y ago
        Oh, cool. I didn't know that.
      - hippich 12y ago
        Yes, you are right, but I found back then that not all code can be compiled without these arrays. Can't remember why right now tho. So there are certainly issues with browsers not supporting typed arrays.
        azakai 12y ago
        Yes, it is tricky to compile without typed arrays. It means we need to disable LLVM optimizations, and also a lot more undefined behavior in C will fail (anything that assumes memory aliasing). With a little effort stuff can be ported, I ported CPython that way. But typed arrays is far better.
ecthiender 12y ago
The Dead Trigger 2[1] game runs amazingly smooth on FF 29.0, Debian, Kernel 3.2 and is amazing to play. I have been playing for quite sometime now, but the only problem is I can't find how to change the guns. There is no menu options or anything. [1] http://beta.unity3d.com/jonas/DT2/ http://beta.unity3d.com/jonas/DT2/
- azakai 12y ago
  Tab changes the guns. Also 1,2,3 do weapon-related effects (one of them is a grenade, I think).
  - ecthiender 12y ago
    Yeah. Found it. 3 throws grenade. Tab - next weapon, q - previous weapon. Played it for an hour or so.
Sir_Cmpwn 12y ago
I'm looking forward to Unity in the browser. The web player has never worked on Linux. Unfortunately, the first demo terminates my browser with a segfault. Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
- azakai 12y ago
  Do other WebGL demos work on your machine? Might be a GL driver issue. Simple test is on http://get.webgl.org/ http://get.webgl.org/
  - Sir_Cmpwn 12y ago
    No. Additional context: Arch Linux, 64-bit, fully updated. Nvidia proprietary drivers, triple headed setup with i3-wm.
    - nawitus 12y ago
      WeBGL works just fine here (Arch Linux, 64-bit, Nvidia drivers [though my browser uses the Intel card]).
- slug 12y ago
  Just tried the angrybots someone mentioned above and it worked just fine (xubuntu 14.04, Linux 3.13, nvidia gtx 670 (driver 331.38), firefox 29)
- nly 12y ago
  Segfaulted for me as well. FF v29.0.1, Arch Linux x86-64, kernel v3.14.3, Intel HD4600 under Mesa/Intel DRI v10.1.3. The WebGL test link posted by azakai does exactly the same thing though. Discussion: https://bbs.archlinux.org/viewtopic.php?id=181408 https://bbs.archlinux.org/viewtopic.php?id=181408 Worked really smoothly on Windows.
  - cpeterso 12y ago
    Does your crash show up in Firefox's about:crashes page? The crash report might show whether it odds the same missing GL symbol the Arch Linux discusses.
comex 12y ago
Not bad. On a related note, it seems that with FTLJIT, Safari now beats Chrome (V8) and Firefox-without-asm.js on asm.js benchmarks: http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=12&view=breakdown&suite=asm... This is great news for anyone for whom V8 was already good enough, although Safari's still handily beaten by Firefox with asm.js mode, which is handily beaten by native. I wonder whether Apple is interested in implementing a special asm.js mode for Safari, which, LLVM being LLVM, might surpass Firefox.
cnaut 12y ago
Makes me think of this video "The Life and Death of Javascript " which brings what the future could be like with asm.js: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
CmonDev 12y ago
I hope one day it will not be possible to run manually-written JS in browser. You would need to use a safer language that compiles into an asm.js module.

162 points by matt42 12y ago

That asm.js demo of Angry Bots [1] is damn slick. In Chrome (2013 macbook air) it's a bit choppy, but on Firefox 30 beta it's very smooth. [1] http://beta.unity3d.com/jonas/AngryBots/ http://beta.unity3d.com/jonas/AngryBots/

camus2 12y ago
works well on FireFox even with an old computer,but yeah it's a catastrophy on Chrome or IE.Good for Firefox that could become the Gaming Browser. Bad for us devs that will have to learn C++ to get good perfs out of game,because you cant write asm.js by end.
- Ygg2 12y ago
  Eh, it's possible to write asm.js just much harder than regular JavaScript. Keep in mind Operating systems were written in assembly, asm.js is not as bad as assembly in some regards.
  - TheZenPsycho 12y ago
    There are constraints to asm.js that are restrictively difficult for a human to maintain. If your code doesn't pass the validator it runs as normal JS.
  - jevinskie 12y ago
    LLJS targeting asm.js may help but it still looks like an early effort. http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available- http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available... https://github.com/jlongster/LLJS https://github.com/jlongster/LLJS
  - camus2 12y ago
    I'm not writing an operating system.The point is you cant get these perfs with using regular javascript.ASM.js is not regular javascript,since it's a subset.
    - Ygg2 12y ago
      No, but this operating system is the example of most performant, least resource hungry application I can think off. If you need performance you don't write C, you write assembly. Same with asm.js.
      - pjc50 12y ago
        You try to avoid writing in assembly unless you absolutely have to, because it's a big maintenance pain and unless all your assumptions are correct it may not be as fast as the compiler. It's not worth bothering with unless you're vectorising or want to use some other instructions that are not normally emitted (e.g. ARM add-with-saturation).
        Ygg2 12y ago
        Yeah, but assembly generally isn't portable (x86 assembly is different than ARM assembly, etc.), that's what makes it biggest pain IIRC. Asm.js on the other hand, is portable and just that makes it way better than any regular assembly. Also it seems better looking than regular assembly (no registers as such, no jumps, etc.). It's a huge step back compared to plain JS, but it's not that impossible to write in.
- k__ 12y ago
  Works "okayish" in Chrome for me.
bjz_ 12y ago
I was really surprised to see it barely using only a fraction of my CPU on my MBP in Aurora (was expecting to see it max out one of my cores). Very cool stuff.

jffry 12y ago

together with all the other work on optimizing asm.js, allows it to run at around 1.5x slower than the speed of the same C/C++ when compiled natively Running at 67% of native speed, and backwards compatible with all non ASM.js browsers? That's pretty great!

hippich 12y ago
I am working on a project based on asm.js technology. From my experience very limited and simple asm.js code might be compatible with "all non asm.js browsers". In particular I found IE9 wouldn't work with some compiled code. IE10 so far so good (but slow of course.)
- nnethercote 12y ago
  asm.js relies on typed arrays, and IE9 doesn't support them. So I'd be surprised if IE9 was able to handle any asm.js code.
  - azakai 12y ago
    Emscripten can emit code without typed arrays. It's fairly slow but does work in IE9.
    - nnethercote 12y ago
      Oh, cool. I didn't know that.
    - hippich 12y ago
      Yes, you are right, but I found back then that not all code can be compiled without these arrays. Can't remember why right now tho. So there are certainly issues with browsers not supporting typed arrays.
      - azakai 12y ago
        Yes, it is tricky to compile without typed arrays. It means we need to disable LLVM optimizations, and also a lot more undefined behavior in C will fail (anything that assumes memory aliasing). With a little effort stuff can be ported, I ported CPython that way. But typed arrays is far better.

ecthiender 12y ago

The Dead Trigger 2[1] game runs amazingly smooth on FF 29.0, Debian, Kernel 3.2 and is amazing to play. I have been playing for quite sometime now, but the only problem is I can't find how to change the guns. There is no menu options or anything. [1] http://beta.unity3d.com/jonas/DT2/ http://beta.unity3d.com/jonas/DT2/

azakai 12y ago
Tab changes the guns. Also 1,2,3 do weapon-related effects (one of them is a grenade, I think).
- ecthiender 12y ago
  Yeah. Found it. 3 throws grenade. Tab - next weapon, q - previous weapon. Played it for an hour or so.

Sir_Cmpwn 12y ago

I'm looking forward to Unity in the browser. The web player has never worked on Linux. Unfortunately, the first demo terminates my browser with a segfault. Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0

azakai 12y ago
Do other WebGL demos work on your machine? Might be a GL driver issue. Simple test is on http://get.webgl.org/ http://get.webgl.org/
- Sir_Cmpwn 12y ago
  No. Additional context: Arch Linux, 64-bit, fully updated. Nvidia proprietary drivers, triple headed setup with i3-wm.
  - nawitus 12y ago
    WeBGL works just fine here (Arch Linux, 64-bit, Nvidia drivers [though my browser uses the Intel card]).
slug 12y ago
Just tried the angrybots someone mentioned above and it worked just fine (xubuntu 14.04, Linux 3.13, nvidia gtx 670 (driver 331.38), firefox 29)
nly 12y ago
Segfaulted for me as well. FF v29.0.1, Arch Linux x86-64, kernel v3.14.3, Intel HD4600 under Mesa/Intel DRI v10.1.3. The WebGL test link posted by azakai does exactly the same thing though. Discussion: https://bbs.archlinux.org/viewtopic.php?id=181408 https://bbs.archlinux.org/viewtopic.php?id=181408 Worked really smoothly on Windows.
- cpeterso 12y ago
  Does your crash show up in Firefox's about:crashes page? The crash report might show whether it odds the same missing GL symbol the Arch Linux discusses.

comex 12y ago

Not bad. On a related note, it seems that with FTLJIT, Safari now beats Chrome (V8) and Firefox-without-asm.js on asm.js benchmarks: http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=12&view=breakdown&suite=asm... This is great news for anyone for whom V8 was already good enough, although Safari's still handily beaten by Firefox with asm.js mode, which is handily beaten by native. I wonder whether Apple is interested in implementing a special asm.js mode for Safari, which, LLVM being LLVM, might surpass Firefox.

cnaut 12y ago

Makes me think of this video "The Life and Death of Javascript " which brings what the future could be like with asm.js: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

CmonDev 12y ago

I hope one day it will not be possible to run manually-written JS in browser. You would need to use a safer language that compiles into an asm.js module.