lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Fri, Nov 19, 2010 at 2:51 PM, Mike Pall <> wrote:
Thank you for the numbers!

You're welcome! These were interesting statistics and will help in optimizing the C++ engine anyway.

Assuming 3d vectors throughout this would give an allocation size
of 8+3*sizeof(double) = 32 bytes for the FFI cdata.

How about using 32-bit floats instead with FFI? Float precision is enough for games and most game engines use them for better cache utilization. 

Ok, so let's pretend for a moment we could kill 90% of the
allocations with some code restructuring and some optimization
magic by the compiler (pure speculation of course). Then you're
down to 1.8% overhead per frame. That sounds acceptable. The new
GC in 2.1 would be much faster at alloc/GC/free, so it will be
even lower in the future.

Yes, I could definitely live with that. Looking forward to 2.1!

> Value semantics ruled out for now, what is your recommendation for vector
> implementation with current version of LuaJIT? Userdata + C operations or
> Lua only implementation with tables? Obviously FFI in the future is the way
> to go, or is it? I would like to keep the functional syntax if at all
> possible.

For LuaJIT, using Lua tables (use array indexes [0], [1], [2]) is
definitely much faster than anything involving userdata and calls
to C code. The FFI will beat that by a substantial amount, though
(I have no exact numbers yet).

Ok, that was my impression as well.

Question: how would vector component indexing work with FFI? If I have a C-type "struct { float x, y, z; }" will "v.x" work in Lua?
I guess that would automatically convert from float to double?