lua-users home
lua-l archive

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

On Nov 19, 2010, at 12:55 AM, Petri Häkkinen wrote:

On Fri, Nov 19, 2010 at 7:59 AM, Mark Hamburg <> wrote:
One step to take if the real concern is Vector3 is implement a suballocator that optimizes this case. Lua 5.2 may also help since it can recognize that Vector3 has no __gc metamethod.

I'm missing something here, how would this be implemented?

You can override Lua's memory allocation function. I would assume that LuaJIT replicates this behavior (though presumably that gets trickier in 64-bit). Having done that, you can do a fast allocator/deallocator for blocks of the size needed for Vector3's. This won't make them as cheap as native types but it will avoid malloc overhead.

The __gc metamethod issue means that when collecting, Lua 5.2 won't bother saving these off onto a list for potential finalization and will instead just free them. That said, a __gc metamethod that could put things into a recycle pool would be cool but would require resurrection support which the Lua GC does not offer. The recycle pool would allow one to avoid setting the metatable on the objects again for recycled vectors.

But all of this will still be slow compared to support for vectors as native values. The more efficient approach in that regard is probably to have both vectors and vector calculators in the system and do most of the math via vector calculators:

calculator( x ):add( y ):times( z ):minus( w ):result()

LuaJIT should happily optimize the method dispatch here.

--[[ At the risk of hurting one's head with tracking types, there is also:

( ( calculator( x ) + y ) * z - w ):result()

This assumes that calculators return themselves in a modified state for arithmetic operations. ]]