Question about LuaJIT and FFI

[yetneverdone]

Hey, so after a while here in the love2d community, ive encountered alot of topics/mentions about the luajit, but i didnt put much thought in it. So after finally being super curious about luajit, ive stumbled upon the FFI library. Which, correct me if im wrong, is binding c/c++(?) to lua.

My questions are:
1. Explain briefly the involvement of luajit to LOVE in particular.
2. Can we use that FFI in love? Please provide a simple code about how so.
3. Will using FFI make gamedev in love a lot easier and faster?

Thanks.

[RaycatRakittra]

I am not an expert on the subject but this is my takeaway from LuaJIT, FFI, and company:

1) LuaJIT is a just-in-time compiler that only works with Lua 5.1. It makes LOVE two to four times faster at the cost of never upgrading to Lua 5.2+. Does that matter to you? Probs not; Lua is weird that way. However, it gives you access to Foreign Function Interface or FFI.

2) Yes, uhh... Stolen from LuaJIT.org:

Code: Select all

local ffi = require('ffi')
ffi.cdef[[
int printf(const char *fmt, ...);
]]
ffi.C.printf("Hello %s!", "world")

Looks like they require it, expose the library as a variable, define a function, and FFI exposes that function on a generic C variable. (I think including Lua in C does something similar with the _L object.)

3) No, it just provides a nice interface for those rascally C/C++ libs you don't wanna port over. There are some performance bumps to be had, though (i.e. using a FFI C array vs a table for heavy computations).

[yetneverdone]

I am not an expert on the subject but this is my takeaway from LuaJIT, FFI, and company:

1) LuaJIT is a just-in-time compiler that only works with Lua 5.1. It makes LOVE two to four times faster at the cost of never upgrading to Lua 5.2+. Does that matter to you? Probs not; Lua is weird that way. However, it gives you access to Foreign Function Interface or FFI.

2) Yes, uhh... Stolen from LuaJIT.org:

Code: Select all

local ffi = require('ffi')
ffi.cdef[[
int printf(const char *fmt, ...);
]]
ffi.C.printf("Hello %s!", "world")

Looks like they require it, expose the library as a variable, define a function, and FFI exposes that function on a generic C variable. (I think including Lua in C does something similar with the _L object.)

3) No, it just provides a nice interface for those rascally C/C++ libs you don't wanna port over. There are some performance bumps to be had, though (i.e. using a FFI C array vs a table for heavy computations).

Thanks! So basically, i can use ffi. Hooray haha

[MasterLee]

I have the following code:

Code: Select all

      local ptr=ffi.cast('unsigned char*',data:getPointer())
      for y=0,height-1 do
        for x=0,width-1 do
          local c=cells[y][x]
          ptr[0]=(c.n%16)*16
          ptr=ptr+1
          ptr[0]=math.floor(c.n/16)*16
          ptr=ptr+1
          ptr[0]=c.pal*8
          ptr=ptr+1
          ptr[0]=(c.xflip and 128 or 0)+(c.yflip and 64 or 0)+(c.dflip and 32 or 0)+1
          ptr=ptr+1
        end
      end

I did the ffi way only, because this solutions came fastest to my mind and that part was not time critical so i did it.
But now i wonder about how much it would be optimized by JIT.

[kikito]

If you want to climb the performance mountains, you must wear measuring boots.

In other words, if you are thinking about performance, you have to write and run performance tests, and compare how different solutions really perform. Human intuition is notably fallible on this particular task.

[zorg]

And even if you heard about things like cache misses, and how to mitigate them (struct of arrays vs. array of structs), you still need to understand that programming languages are dissimilar to each other; maybe lua itself can not be used in such ways (because of tables being generic containers) but C structs/arrays via FFI can, probably; grain of salt, i don't really know either if this particular thing can be used or not here.

[raidho36]

Also, LuaJIT alone, without any JIT compilation, is faster than vanilla Lua. Jit compilation improves performance to anywhere between 10 and 200 times, and brings it on par with C if you don't use Lua tables.

[SPlice]

you can do a lot of cool stuff with FFI if you are willing to create c libraries as .dll files

[Xii]

If you want to climb the performance mountains, you must wear measuring boots.

In other words, if you are thinking about performance, you have to write and run performance tests, and compare how different solutions really perform. Human intuition is notably fallible on this particular task.

I know this is an old thread, but I wanted to chip in my results.

A simple test of 3000 objects with linear integration of movement (direction and speed) runs at 60 fps on my machine.
The same test, with the objects placed in an FFI-allocated array/struct, is actually slower to iterate through, only managing 2000 at 60 fps.
The only upside is less memory use, since not all members necessitate a 64-bit variable.

[slime]

One potential cause is some bit of code in your loop might be preventing the loop from being JIT compiled. Another potential cause is if the values in the FFI array are not stored as doubles, LuaJIT will have to convert between the storage format and double, which can hurt performance in an inner loop. LuaJIT provides some tools to help identify those sort of things, although they aren't necessarily trivial to use with love.