Hacker News new | comments | show | ask | jobs | submit login

You can't simply asm.js'fy LuaJIT2 because it has an interpreter hand written in assembly and it generates native code to achieve peak performance. You can only asm.js'fy a normal Lua interpreter which is up to 64x slower than LuaJIT on benchmarks, when compared natively. So asm.js'fied Lua will be up to 128x slower. Does not sound that impressive...

Hi -- you make a good point, the one seemingly at issue in this tangent (but not really the bone of contention).

As noted, I don't know which will ultimately prevail in pure performance: DartVM or Dart2JS on evolved JS. In the near term, of course DartVM wins (and that investment made "against cross-browser standards" was the strategic bone of contention 594 days ago).

I do know that in the foreseeable term, we browser vendors don't all have the ability to build two VMs (or three, to include Lua using LuaJIT2 or something as fast, in addition to JS and Dart; or more VMs since everyone wants Blub ;-).

The cross-heap cycle collector required by two disjoint VMs sharing the DOM already felled attempts to push Dart support into WebKit over a year ago. Apple's Filip Pizlo said why here:


Other browser vendors than Apple may have the resources to do more, but no browser wants to take a performance hit "on spec". And Mozilla at least has more than enough work to do with relatively few resources (compared to Apple, Google, and Microsoft) on JS. As you've heard, asm.js was an easy addition, built on our JIT framework.

So you're right, an optimizing JIT-compiling VM is not easily hosted via a cross-compiler, or emulated competitively by compiling to JS. LuaJIT2 would need a safe JIT API from the cross-compiler's target runtime, whether NaCl/PNaCl's runtime or Emscripten/asm.js's equivalent.

Googling for "NaCl JIT" shows encouraging signs, although the first hit is from May 2011. The general idea of a safe JIT API can be applied to asm.js too. In any event, one would need to write a new back end for LuaJIT2.

Bottom line: we're looking into efficient multi-language VM hosting via asm.js and future extensions, but this is obviously a longer road than C/C++ cross-compiling where we've had good early wins (e.g., Unreal Engine).

> You can only asm.js'fy a normal Lua interpreter which is up to 64x slower than LuaJIT on benchmarks

Yes, LuaJIT is fast, but even their own numbers are nowhere near 64x being the mean or median,


Furthermore, these are microbenchmarks. Large codebases might paint a different picture.

I am also not sure why LuaJIT is the most interesting comparison. Yes, LuaJIT is a work of art, but even normal Lua is quite fast, beating Python and Ruby easily. So even a half-speed Lua-VM-in-JS would be competitive with other dynamic languages - which means it is fast enough for many uses.

Finally, we can certainly compile VMs that JIT, we just need to create JIT backends for them that emit JS (preferably asm.js). But LuaJIT is more tricky, as you note, because it lacks a portable C interpreter.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact