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.
