+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: LuaJIT (/thread-1418.html)
LuaJIT - worktycho - 03-24-2014
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.
RE: LuaJIT - worktycho - 03-24-2014
Anyone have any thoughts on which option to go for?
RE: LuaJIT - xoft - 03-24-2014
Would it be that difficult to make it work with CMake?
RE: LuaJIT - worktycho - 03-24-2014
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.
RE: LuaJIT - NiLSPACE - 03-30-2014
I do think we should integrate LuaJIT into MCServer because every speed up we get from it is usefull.
RE: LuaJIT - xoft - 03-30-2014
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.
RE: LuaJIT - bearbin - 03-31-2014
We tried it in school and LuaJIT using the luadist CMake file works on the RPi.
RE: LuaJIT - worktycho - 03-31-2014
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.
RE: LuaJIT - NiLSPACE - 12-26-2015
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.
RE: LuaJIT - LogicParrot - 12-26-2015
(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()
endIn general, Lua is much faster with locals. I don't think this justifies LuaJit. Just make a local before a tight loop.