lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

According to Mike, if I'm not wrong,

FFI is way slower with JIT turned off. I guess lots of stack manipulation has to be done in iterative way (no codegen)

FFI is very fast, if not faster than statically compiled code when JIT is on (it can generate the optimal calling code, and for DLL's it can directly put jmp <absolute address>, instead of going through table). I also remmember that Mike was tracking how the function was behaving after the first call - whether it was calle save, or caller save - so he can "memoize" this and reuse it later, and maybe other "magical" stuff too :)

Nonetheless, the idea of using LuaJIT as FFI embedding device, even with JIT turned off is not bad. I'm finding myself now relying on this, but soon or later you would hit situation where a callback needs to be provided, and that callback would have to be your lua function. That is still no implemented yet. (for example - Win32 RegisterClass with WindowProc, or qsort with sorting function). Also one can't reuse the same LuaJIT context for the callback, has to be new one.

On 6/22/2011 9:07 PM, HyperHacker wrote:
On Wed, Jun 22, 2011 at 19:51, Josh Haberman<>  wrote:
HyperHacker<hyperhacker<at>>  writes:
I was just wondering to myself if LuaJIT could ever be hacked to
function as a Lua compiler, that compiles scripts to standalone
executables or libraries.

By "standalone executable" do you mean:

1. one that embeds the LuaJIT and the Lua program, or
2. one that contains machine code for the original Lua program,
   but not LuaJIT or Lua program itself.

(1) is not very difficult.

(2) is not feasible, AIUI.  LuaJIT can only generate fast code
when it can observe runtime traces.  These traces are not
something that can be generated ahead-of-time, because they
depend on eg. the actual types of variables.  Even if they could
be generated ahead-of-time, the runtime profile of the program
could change as it is running; a tracing JIT can adapt to this,
but AOT compiling could not, which would compromise performance.

Also, since the slow paths of the JIT-ted code fall back to
the interpreter, you'd have to include LuaJIT's interpreter in
the standalone executable.


I hadn't thought of the idea of just statically linking Lua and LuaJIT
into a program, but that's probably a better and more feasible
approach to making standalone executables than trying to compile to
native code. What I was more interested in though was the possibility
of writing a Lua module, which uses the FFI to do things that normally
would require dropping down to C (typically bindings to C libraries),
and being able to compile it into a shared object file that could then
be loaded and used by Lua without LuaJIT.

Doing so by including LuaJIT in the module is still an interesting
idea, but means your module will be rather large, and wastes space if
you have more than one and/or you're using LuaJIT anyway.

By the sounds of it, LuaJIT itself can't feasibly compile to native
code, but I'm still curious about the possibility of writing bindings
to C libraries entirely in Lua, without depending on LuaJIT for the

Sent from my toaster.