LuaJIT - Printable Version

LuaJIT - Printable Version

+- 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)

Pages: 1 2 3

RE: LuaJIT - NiLSPACE - 12-26-2015

Of course I know that locals are faster. If I didn't know that my plugins would be awfully slow Tongue

But what you're using here isn't OOP. You're just getting a static function, putting it in a variable and calling. That won't work well with actuall methods. For example, look at the code I used for my test:

Code:

local MyClass = {}

function MyClass:new()
	local Obj = {}
	setmetatable(Obj, self)
	self.__index = self
	
	Obj.TestVar = math.random(50)
	
	return Obj
end

function MyClass:Test()
	local R = self.TestVar + 50
end

local startTime = os.clock()
local Constr = MyClass:new()
for I = 1, 1000000000 do
	Constr:Test()
end
print(os.clock() - startTime);

It's a really simple example of a class in Lua. What I could do is get the "Test" function and make it a local. Then give the object as a parameter, but how are you planning on making the TestVar variable a local? It's also of course not pretty to use that.

RE: LuaJIT - LogicParrot - 12-26-2015

local MyClass = {}

function MyClass:new()
	local Obj = {}
	setmetatable(Obj, self)
	self.__index = self
	
	Obj.TestVar = math.random(50)
	
	return Obj
end

function MyClass:Test()
	local R = self.TestVar + 50
end

local startTime = os.clock()
local Constr = MyClass:new()
local test = Constr.Test
for I = 1, 1000000000 do
	test(Constr)
end
print(os.clock() - startTime);

RE: LuaJIT - NiLSPACE - 12-26-2015

Yes, but you're still accessing the TestVar variable 1000000000 times from the table. It still takes 67.455 in Lua, while it takes 0.419 seconds in LuaJit.

RE: LuaJIT - LogicParrot - 12-26-2015

I just tested that. It was ~50 seconds while your original code was 60 Tongue

Let me try to come up with some hacky way to make the other variable local too, it'd be interesting to compare. Though it would certainly not be tidied code.

This one took 9 seconds:

local MyClass = {}

function MyClass:new()
    local Obj = {}
    setmetatable(Obj, self)
    self.__index = self

    Obj.TestVar = math.random(50)

    return Obj
end

local startTime = os.clock()
local Constr = MyClass:new()
local R = Constr.TestVar
for I = 1, 1000000000 do
    R = R + 50
end
Constr.TestVar = R
print(os.clock() - startTime);

You have a point.

RE: LuaJIT - LogicParrot - 12-26-2015

Interestingly, this variation also took ~60 seconds even though it doesn't use tables inside the loop.

local MyClass = {}
 
function MyClass:new()
    local Obj = {}
    setmetatable(Obj, self)
    self.__index = self
     
    Obj.TestVar = math.random(50)
     
    return Obj
end
 
function Test(val)
    return val + 50
end
 
local startTime = os.clock()
local Constr = MyClass:new()
local test = Test
R = Constr.TestVar
for I = 1, 1000000000 do
    R = test(R )
end
Constr.TestVar = R
print(os.clock() - startTime);

RE: LuaJIT - NiLSPACE - 12-26-2015

That's because it's trying to get the variable R which is inside the global table (print(_G)). If you make R a local variable it should be a whole lot faster, but I can hardly call it OOP then Tongue

RE: LuaJIT - NiLSPACE - 12-27-2015

Whoah, I can just copy the LuaJit dll and replace it with lua51.dll. It actually works Tongue

When executing my example code it was done in 0.426 seconds.

OOh, and goto's are working in LuaJit Big Grin

And even the FFI works Smile

I also heard that raw byte code is portable across every architecture that LuaJit supports. This way people could create closed source plugins if they wanted to.

RE: LuaJIT - NiLSPACE - 12-28-2015

@worktycho is it still really hard to use LuaJit instead of Lua? If I remember correctly you said LuaJit doesn't have an ANSI mode like Lua, but isn't the server now using Unicode since a PR made by Tigerw?

RE: LuaJIT - worktycho - 12-28-2015

That isn't the main issue. The big problems are: luaJIT is not ISO C, or POSIX, so we need to reduce our target platform support, or support both luajit and lua. Also LuaJIT has a complex build system, that hasn't been ported to cmake other than x86, so we lose the all in one build system.

RE: LuaJIT - LogicParrot - 12-28-2015

So it's a choice between performance and portability. Since the former is already good enough for almost all plugin use cases, the logical choice is choosing portability.