LuaJIT

[worktycho]

As a result of STRWarrior's posts on terrain generation I had a look at embedding luaJIT into MCServer. In terms of code it should pose no problems, its API and ABI compatible. However it is much harder to build. They provide a Makefile and a batch script for compiling and form what I've seen rewriting the build system in cmake is not an option.

This leaves me with four possible plans:
1) Detect make and run their makefile, otherwise try to get a windows dev console and use the batch script, otherwise fall-back to lua.
2) Use the luadist CMakeList on x86, otherwise lua.
3) Use the luaDist CMakeList on x86, otherwise as per 1)
4) Ask the user to build luaJIT, otherwise use lua.

Option 1 is the most likely to work but is complicated. We already discussed that the windows dev console wont work in relation to tolua so this would probably be POSIX/mingw only.
Option 2 is the most likely to work on windows and is the simplest automatic option but means we lose luaJIT where we most need it, Android and pis.
Option 3 is the most complicated and will likely be very buggy but covers the most systems automatically.
Option 4 is simplest for write but is hardest for users.

[worktycho]

Anyone have any thoughts on which option to go for?

[xoft]

Would it be that difficult to make it work with CMake?

[worktycho]

I'd have to rewrite the 800 lines of makefile as luaJIT doesn't have an ansi mode like lua. luaJIT needs has more specific needs because it is doing codegen. If the c++ code doesnt match what the JIT expected it can cause an application crash.

[NiLSPACE]

I do think we should integrate LuaJIT into MCServer because every speed up we get from it is usefull.

[xoft]

I think our priorities should be elsewhere. Although LuaJIT would be nice to have, it's a replacement for something that already works and it works great already, so let's postpone this until we get other, more painful areas sorted out. Such as the networking rewrite, Lua sockets and Lua ODBC libs.

[bearbin]

We tried it in school and LuaJIT using the luadist CMake file works on the RPi.

[worktycho]

It sort of works, I couldn't get the lua test suite to run because it doesnt support relative paths, it just has a search path.

[NiLSPACE]

I found another reason for moving to LuaJit. Accessing tables is much faster making OOP much faster. Accessing a method in a table 1.000.000.000 times took 93.534 seconds in Lua, while it only took 0.425 seconds in LuaJit.

Now, naturally it won't happen allot that a plugin would call a method a billion times, but in the WorldEdit plugin I sometimes had to define a function locally instead of calling it from the table because the performance impact would otherwise be too great.

[LogicParrot]

I found another reason for moving to LuaJit. Accessing tables is much faster making OOP much faster. Accessing a method in a table 1.000.000.000 times took 93.534 seconds in Lua, while it only took 0.425 seconds in LuaJit.

Now, naturally it won't happen allot that a plugin would call a method a billion times, but in the WorldEdit plugin I sometimes had to define a function locally instead of calling it from the table because the performance impact would otherwise be too great.

Try creating a local reference to the method before calling it 1,000,000,000 times. I believe you'd get very similar performace.

e.g.

Code:

local foo = myTable.Function;
for i = 0, 1000000000 do
  foo()
end

In general, Lua is much faster with locals. I don't think this justifies LuaJit. Just make a local before a tight loop.