Live data from Hacker News

Compiling LLJS to asm.js

jlongster.com

31–35 of 35 posts

Re: Compiling LLJS to asm.js

#31

Yesterday I rewrote a tiny Javascript demo in asm.js and also saw an order-of-magnitude speedup. (I thought at first it didn't help at all, apparently because the framerate was limited by setInterval().) Code at http://wry.me/hacking/canvas_asm.html

Doesn't appear to be doing anything for me, noasm 285 asm 13 asm 13 noasm 269 That's all that appears in the console. Network and everything looks fine, no 404 or other errors.

I wonder if most / all of that speedup is just using typed arrays (edit: nvm, they both do). I get similar speeds in Chrome, which afaik doesn't have any special handling for `"use asm";` functions.

Re: Compiling LLJS to asm.js

#32
post #30
post #15

LLJS, asm.js, & Emscripten are really moving Javascript forward at incredible speed. I wonder if these projects will affect the future of the JS spec (ECMAScript Harmony + above). It's an exciting time to be a web programmer.

These projects are already affecting the spec. Here's a very small example: https://mail.mozilla.org/pipermail/es-discuss/2012-November/... which is used in asm.js and already implemented in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=808148

This was added to Gecko 20.0, but it isn't part of the specs.

V8 doesn't support it: http://code.google.com/p/v8/issues/detail?id=2455

Re: Compiling LLJS to asm.js

#33
post #31

Earlier quoted context omitted.

Doesn't appear to be doing anything for me, noasm 285 asm 13 asm 13 noasm 269 That's all that appears in the console. Network and everything looks fine, no 404 or other errors.

I wonder if most / all of that speedup is just using typed arrays (edit: nvm, they both do). I get similar speeds in Chrome, which afaik doesn't have any special handling for `"use asm";` functions.

Typed arrays do deliver a lot of speedup, and in fact, the above example is slightly faster in Chrome than in Firefox Nightly for me. However, if your algorithm does crunch a lot of data in a low-level way, there is definitely even more performance you can get by using asm.js.

See my link in the comment below for benchmarks of a sha1 algorithm that shows a good speedup in Chrome by using TypedArrays, but an even greater one in OdinMonkey.

Re: Compiling LLJS to asm.js

#34
post #33
post #31

Earlier quoted context omitted.

I wonder if most / all of that speedup is just using typed arrays (edit: nvm, they both do). I get similar speeds in Chrome, which afaik doesn't have any special handling for `"use asm";` functions.

Typed arrays do deliver a lot of speedup, and in fact, the above example is slightly faster in Chrome than in Firefox Nightly for me. However, if your algorithm does crunch a lot of data in a low-level way, there is definitely even more performance you can get by using asm.js. See my link in the comment below for benchmarks of a sha1 algorithm that shows a good speedup in Chrome by using TypedArrays, but an even grea…

awesome - thanks for doing the legwork! I'll definitely take a look.

Re: Compiling LLJS to asm.js

#35
post #30
post #15

LLJS, asm.js, & Emscripten are really moving Javascript forward at incredible speed. I wonder if these projects will affect the future of the JS spec (ECMAScript Harmony + above). It's an exciting time to be a web programmer.

These projects are already affecting the spec. Here's a very small example: https://mail.mozilla.org/pipermail/es-discuss/2012-November/... which is used in asm.js and already implemented in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=808148

Math.imul is just an ad-hoc patch to improve the performance of Emscripten. It's totally for Firefox. Is there a motivation to standardize and implement such a thing for other browser vendors? I'll star the V8 issue though...
Post reply on HN