LuaJIT
#1
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.
Reply
Thanks given by:
#2
Anyone have any thoughts on which option to go for?
Reply
Thanks given by:
#3
Would it be that difficult to make it work with CMake?
Reply
Thanks given by:
#4
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.
Reply
Thanks given by:
#5
I do think we should integrate LuaJIT into MCServer because every speed up we get from it is usefull.
Reply
Thanks given by:
#6
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.
Reply
Thanks given by: LogicParrot
#7
We tried it in school and LuaJIT using the luadist CMake file works on the RPi.
Reply
Thanks given by:
#8
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.
Reply
Thanks given by:
#9
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.
Reply
Thanks given by:
#10
(12-26-2015, 09:56 PM)NiLSPACE Wrote: 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.
Reply
Thanks given by:




Users browsing this thread: 4 Guest(s)