Re: Avoiding LuaJIT FFI allocations (Was: LuaJIT - Is ffi.alloca possible?)

[Adam Strzelecki <ono@...>]

> I took a different approach, where instead of relying on luajit returning me fresh new scalars or vectors, I was providing them instead, which means I had to make sure these are preallocated in some way:(…)

Unfortunately this approach excludes usage of overloaded operators and make code less readable. So instead of expected/wanted syntax:
  modelView = view * model

I would need to write something like that:
  mcopy(modelView, view)
  mmul(modelView, model)

And this is what I want to avoid, I don't want the code to look like plain C or assembly.

I did try already to override __gc for my matrix MT and keep released structures in some kind of cache, unfortunately in tight loops dealllocs are called after to whole loop is finished, so the sequence for 'i = 1, 1000000 do res = mat1 * mat2 end' looks more like 1000000 allocs and then 1000000 deallocs, rather than 1000000 interleaved alloc+dealloc. So caching does not really work there.

> I was satisfied with the results, because there was no memory allocation, and even the assembly looked good (but then Mike came and said - NOT GOOD ENOUGH :) :) :) :) - but to me... juuuust fine!)

Yeah, the capabilities of LuaJIT for SSE code generation are simply amazing. This is main reason I've decided to explore LuaJIT and Lua itself.

Now I wonder if I can make it any better keeping the overloaded operators + simple syntax.

I've read in few places that Mike plans to implement "allocation sinking", however I couldn't find good some good reference for this technique and explanation whether it can help in this case.

Also I don't know if it would be possible to implement C scalar types accessible via FFI as scalars in Lua (kept completely on Lua stack), so i.e. vector types declared with 'float __attribute__ ((vector_size (64)))' would make me scalar 4x4 matrix. Probably not as stack entries are fixed size, much smaller than 64 bytes.

Cheers,
-- 
Adam