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