Re: LuaJIT with vectors

[Mike Pall <mikelu-1011@...>]

Mark Hamburg wrote:
> 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.

This is often suggested, but rarely beneficial. All modern malloc
implementations already do exactly that: they keep lists of blocks
for common sizes and recycle them. So you're just duplicating
their work and slow down everything else with an extra indirection.

Instead one should tune the malloc implementation to the usage
patterns of the language. This is what I did with the built-in
allocator in LuaJIT (a heavily modified dlmalloc descendant).

OTOH I've considered a ffi.pool add-on module. It allocates a big
array of a user-defined C type and deals out references to its
elements. The pool itself is subject to GC, but the elements are
not. For most purposes you can treat the elements like
individually allocated objects.

[The references are of course cdata objects themselves. But these
are trivial to eliminate for the JIT compiler.]

> The __gc metamethod issue [...]

FFI cdata != userdata. It's an extra type. I'll add per-ctype
metatables later, but they won't support __gc to avoid all of the
related issues. Ceterum censeo: finalizers are evil.

--Mike