4 ms·

I don't know much about Lua and LuaJIT, so let me ask a naive question: If you would start out with a JavaScript JIT (like V8) what things would you have to ad

by sdf45 11y ago

I don't know much about Lua and LuaJIT, so let me ask a naive question: If you would start out with a JavaScript JIT (like V8) what things would you have to add (i.e. things that are not required to JIT JavaScript) besides the obvious modifications in the parser? One point I can think of is support for efficient compilation of co-routines.

wolf550e 11y ago
The reason people use LuaJIT instead of v8 is because LuaJIT is faster than v8 (on some code) and is smaller and is more easily embeddable. Or at least that is my impression, I have no personal experience with it.
- malkia 11y ago
  For me the main reason was the FFI, even if back in the day it did not support re-entrance - e.g. something in the "C" land has to call back "lua" land. But the JIT in luajit is simply too impressive to skip it over. I was able to quickly prototype things with it, running almost at "C" speed, and some times even faster.
camperman 11y ago
There's a in-depth discussion of those issues with respect to both LuaJIT and Javascript here: http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851
yoklov 11y ago
Lua has goto (and JS does not), which means not all cfg's are well structured. That could impact the compiler in certain ways. Lua also has finalizers, which effect the GC's design. The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way (but to my knowledge LuaJIT doesn't support 5.3 so...) There are other issues too, but these are just off the top of my head.
- striking 11y ago
  LuaJIT supports the 5.1 Lua standard, so goto doesn't exist. Yeah, finalizers and weak key value stores would be an issue in certain versions of JS.
  - pygy_ 11y ago
    LuaJIT supports goto out of the box, as well as many other Lua 5.2 features, some behind à compiler flag.
    - striking 11y ago
      I stand corrected. Thanks!
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- mraleph 11y ago
  > Lua also has finalizers, which effect the GC's design. V8 has a weak callback mechanism, which (while not exposed to JS) allows reentering JS from inside a weak callback - which means you can emulate Lua's __gc on top of this mechanism. > The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. If we disregard lua_topointer then Lua/C API only leaks internal pointers for strings (lua_tostring), userdata (lua_newuserdata, lua_touserdata) and threads (lua_newthread,lua_tothread) - everything else is manipulated using lua_State's stack. This means VM only has to take care with regards to these objects. Userdata and threads can be just allocated outside of movable part of the heap and strings can be "externalized" (i.e. they payload relocated into the immovable space) on first access via lua_tostring. Coincidentally last thing is something that V8 supports[1] (though of course externalization is not a cheap operation as it requires copying). > Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way Yeah, that's certainly a whole ton of work, but most of this work would be pretty technical. JS engines might actually get int64/uint64 value types in the future (at some point there was an ES7 proposal - but currently it does not seem to be on track for inclusion). [1] https://github.com/v8/v8-git-mirror/blob/master/include/v8.h#L2344-L2353 https://github.com/v8/v8-git-mirror/blob/master/include/v8.h...
haberman 11y ago
> If you would start out with a JavaScript JIT (like V8) what things would you have to add (i.e. things that are not required to JIT JavaScript) besides the obvious modifications in the parser? This is such a tempting thought -- that JavaScript and Lua are similar enough languages that an engine for one could be retargeted to the other with some parser changes and a few new features. In practice it doesn't work out that way. Here is the story of Tessel, who originally set out to do it the other way around (implement JavaScript on LuaJIT) but reversed course after two years: https://tessel.io/blog/112888410737/moving-faster-with-iojs https://tessel.io/blog/112888410737/moving-faster-with-iojs "We believed that over time we could cover all of the corner cases of JavaScript with our own runtime, but perhaps we should have taken a cue from the “Wat talk” that it was going to be an uphill battle. While the semantics between JavaScript and Lua are very similar, they are also just slightly different in many ways (For example, the comparisons between null vs undefined vs falsy), and capturing all of those idiosyncrasies has proved frustrating for both the users and developers of the Runtime. [...] I still do believe it’s possible to make a nearly compatible runtime, but it’s going to take much more work than we expected and that resource investment would be an unwise business decision."
barkingcat 11y ago
I'd think that the javascript JIT would need to be gutted and extensively re-engineered. There's a reason why each language has their own jit - in order to speed up specifics parts of the language. While certain things are similar, the specific optimizations I'm sure follows the spec of the language so closely that it's not readily transferable to other languages. The general optimization strategies, like tracing, etc are techniques that can be ported, but if you start with a highly optimized jit for javascript, you're gonna have to rewrite large portions - so much that it would as much works as rewriting luajit from scratch.

by sdf45 11y ago

wolf550e 11y ago

The reason people use LuaJIT instead of v8 is because LuaJIT is faster than v8 (on some code) and is smaller and is more easily embeddable. Or at least that is my impression, I have no personal experience with it.

malkia 11y ago
For me the main reason was the FFI, even if back in the day it did not support re-entrance - e.g. something in the "C" land has to call back "lua" land. But the JIT in luajit is simply too impressive to skip it over. I was able to quickly prototype things with it, running almost at "C" speed, and some times even faster.

camperman 11y ago

There's a in-depth discussion of those issues with respect to both LuaJIT and Javascript here: http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851

yoklov 11y ago

Lua has goto (and JS does not), which means not all cfg's are well structured. That could impact the compiler in certain ways. Lua also has finalizers, which effect the GC's design. The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way (but to my knowledge LuaJIT doesn't support 5.3 so...) There are other issues too, but these are just off the top of my head.

striking 11y ago
LuaJIT supports the 5.1 Lua standard, so goto doesn't exist. Yeah, finalizers and weak key value stores would be an issue in certain versions of JS.
- pygy_ 11y ago
  LuaJIT supports goto out of the box, as well as many other Lua 5.2 features, some behind à compiler flag.
  - striking 11y ago
    I stand corrected. Thanks!
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
mraleph 11y ago
> Lua also has finalizers, which effect the GC's design. V8 has a weak callback mechanism, which (while not exposed to JS) allows reentering JS from inside a weak callback - which means you can emulate Lua's __gc on top of this mechanism. > The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. If we disregard lua_topointer then Lua/C API only leaks internal pointers for strings (lua_tostring), userdata (lua_newuserdata, lua_touserdata) and threads (lua_newthread,lua_tothread) - everything else is manipulated using lua_State's stack. This means VM only has to take care with regards to these objects. Userdata and threads can be just allocated outside of movable part of the heap and strings can be "externalized" (i.e. they payload relocated into the immovable space) on first access via lua_tostring. Coincidentally last thing is something that V8 supports[1] (though of course externalization is not a cheap operation as it requires copying). > Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way Yeah, that's certainly a whole ton of work, but most of this work would be pretty technical. JS engines might actually get int64/uint64 value types in the future (at some point there was an ES7 proposal - but currently it does not seem to be on track for inclusion). [1] https://github.com/v8/v8-git-mirror/blob/master/include/v8.h#L2344-L2353 https://github.com/v8/v8-git-mirror/blob/master/include/v8.h...

haberman 11y ago

> If you would start out with a JavaScript JIT (like V8) what things would you have to add (i.e. things that are not required to JIT JavaScript) besides the obvious modifications in the parser? This is such a tempting thought -- that JavaScript and Lua are similar enough languages that an engine for one could be retargeted to the other with some parser changes and a few new features. In practice it doesn't work out that way. Here is the story of Tessel, who originally set out to do it the other way around (implement JavaScript on LuaJIT) but reversed course after two years: https://tessel.io/blog/112888410737/moving-faster-with-iojs https://tessel.io/blog/112888410737/moving-faster-with-iojs "We believed that over time we could cover all of the corner cases of JavaScript with our own runtime, but perhaps we should have taken a cue from the “Wat talk” that it was going to be an uphill battle. While the semantics between JavaScript and Lua are very similar, they are also just slightly different in many ways (For example, the comparisons between null vs undefined vs falsy), and capturing all of those idiosyncrasies has proved frustrating for both the users and developers of the Runtime. [...] I still do believe it’s possible to make a nearly compatible runtime, but it’s going to take much more work than we expected and that resource investment would be an unwise business decision."

barkingcat 11y ago

I'd think that the javascript JIT would need to be gutted and extensively re-engineered. There's a reason why each language has their own jit - in order to speed up specifics parts of the language. While certain things are similar, the specific optimizations I'm sure follows the spec of the language so closely that it's not readily transferable to other languages. The general optimization strategies, like tracing, etc are techniques that can be ported, but if you start with a highly optimized jit for javascript, you're gonna have to rewrite large portions - so much that it would as much works as rewriting luajit from scratch.