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

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

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

Cool. I recently wrote a low-level sha1 implementation in pure javascript, trying to leverage asm.js (http://github.com/srijs/rusha).

Can you tell me, how did you confirm you wrote valid asm.js and there was no fallback-mechanism kicking in?

I benchmarked my implementation, of course, and noticed a 2x speedup. However, this seems quite less for the this type of low-level algorithm...

Open the error console (via the Web Developer menu item) and you'll see messages there. Success shows up as "Error: successfully compiled asm.js code." :-)

P.S. Looking at your code, I can tell it's not asm.js conformant yet, though it should just be a bunch of small tweaks (e.g. an expression like (a+b) will need to be (a+b)|0, etc.).

Thank you. I just updated my code and it's really within half of native speed now... (benchmarks in the README, if any of you are interested)

asm.js is very exciting technology!

You're welcome!

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.

Yes, I disabled display so that wouldn't get into the benchmark. The numbers are times in milliseconds.

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.

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

That is the most exciting news I've heard in quite a while.

Whats the use for LLJS ? I dont really get it. So its not meant to be used in web development but for things like games or complete VMs. But isnt it much simpler for those cases to compile existing C codebases with emscripten instead of rewriting everything in LLJS ? Even if you start today with writing a new game engine, wouldnt it make more sense to use C++ and be able to target any platform there is instead of just the browser?

The main use for something like LLJS is to allow you to target asm.js with new code that you write. It's true that it's probably not the best idea to completely rewrite a 3d engine in it (right now), but it gives you a quick way to rewrite core parts of an intensive app (like a 3d game) for high performance. There are "inner loops" that could benefit from a small amount of LLJS.

As the post says, it's a proof of concept and a way to open up asm.js to people who want to tinker with it without compiling C code with emscripten.

I see, so the main benefit vs compiling c to asm.js is that the development process is easier because you dont need to manually compile. Sounds interesting to use as a scripting language inside a c based game engine. So the core of the engine would be directly compiled to asm.js while the game logic scripting could be done in LLJS to be able to live-test your game.

That's certainly a possibility! It would be neat to see powerful debugging tools develop, after the language stabilizes. I also like the idea of somehow linking it with emscripten-compiled code so that it can be used as a sort of scripting language.

I'd like to explore the possibility of porting some of the C toolchain to the browser too, though. It's possible that it could be quite successful, and in that case LLJS would target people who just want to write small parts of there app for asm.js.

sounds really exciting, keep up the great work!

For a big codebase, yes, compiling C/C++ using emscripten or such is a good idea. But if you want to write a tiny part of a normal JS application in something faster, lljs is convenient. Sort of like you would write inline assembly in C perhaps.

Has anyone built the entire stack in javascript (C to JS compiler in JS + standard library) so that you could write JS applications in C and compile and run in the browser?

EDIT: to clarify, the ideal solution would be an editor (like codemirror or ace) with a compile+run button that would compile the code down to JS and run it.

That's exactly what emscripten does, and is very mature and being used to port massive 3d games to the web.

https://github.com/kripken/emscripten

See the BananaBread demo: https://developer.mozilla.org/en-US/demos/detail/bananabread

You have to use the command-line `emcc` tool to do this. I'm asking if that tool can be eliminated from the workflow.

The ideal solution would be an editor (like codemirror or ace) with a compile+run button that would compile the code down to JS and run it.

Oh, I see. No, not yet, I think the C compilers are complex enough to be difficult to compile with emscripten. I have no evidence for that, but I know they are incredibly complex.

The shorter path is something like LLVM, but we could see something like a compiler all in js that can take a large subset of C and compile it.

EDIT: see azakai's comment below which provides much better insight into this

I think what the parent was asking was could libraries be written in C (for example jQuery) where performance is critical.

That's LLVM -> JS. Has anyone built Clang using emscripten (that would be the C -> LLVM piece)?

I've built parts of LLVM itself,

http://kripken.github.com/llvm.js/demo.html

Which translates LLVM IR into LLVM bitcode, and then emscripten can translate to JS, all in the browser.

No reason clang couldn't be compiled too, I imagine someone someday will do it when there's a need.

The C++ LLVM library is hard to compile to js. Didn't succeed last time[1].

[1] https://github.com/kripken/emscripten/issues/579

I am sure there is some reason this can't be done, but can we compile JavaScript to asm.js? If this can be done with C, it can be done with JS?

Sure, but it's different because you need to compile a whole VM to asm.js and run javascript inside of it. You can't compile a dynamic language like javascript to low-level code because you need too much information at runtime.

See this project, which compiles SpiderMonkey to javascript via emscripten, which supports asm.js: https://github.com/jterrace/js.js/

qt-emscripten does something similar, it builds the JSC interpreter together with Qt.

How far are we from being able to do meaningful text processing with typed arrays and (therefore, presumably) asm.js? Last I checked, there was work being done on a string encoding/decoding standard but it wasn't implemented in browsers yet. Can anyone say more about this?