lua-users home
lua-l archive

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


Diego Nehab wrote:
>>>> local midentity = matrixh()
>>>> local valtitude = vector()
>>>> function model:update_fast()
>>>>    local global_matrix = self.global_matrix
>>>>    geometry.matrixh.copy(global_matrix, midentity)
>>>>    global_matrix:rotate(self.orbital_orientation)
>>>>    valtitude.y = self.altitude
>>>>    global_matrix:translate(valtitude)
>>>>    global_matrix:rotate(self.orientation)
>>>>    global_matrix:translate(self.position)
>>>> end
>>>> 
>>>> And even if that optimized form is acceptable for entity update,
>>>> for skeletal animation of a couple hundred of entities with 64
>>>> bones each it just takes too much time to run at interactive
>>>> framerate, so instead I rewrite these critical bottlenecks in C.
>>> 
>>> If you are willing to use this syntax, you could perhaps go the next
>>> step and use light user data for matrices? You could then completely
>>> avoid Lua's garbage collection (and production).
>> 
>> With the above syntax I avoid most object creation, and at that point
>> unfortunately the cost of Lua->C function calls become the
>> bottleneck. 
> 
> I agree that if this is the only function you use, you'd save on the
> object creation with your current syntax. 
> 
> But there is also the cost of metatable access, which I don't think
> is free. If you had copy/translate/rotate as local variables, you
> might gain some performance.

Yeah, that's right, I didn't try to cache these functions.

> Also, what are you doing for error
> checking once you receive the "userdata" within the C functions bound
> to copy/translate/rotate?    

Most of the time I check their type with luaL_checkudata, which involves
a table lookup. Some function accept several different types, so in that
case I use lua_getmetatable, luaL_getmetatable and lua_rawequal. For
extra performance I could avoid type checking and do it manually in the
Lua sources.

But should I have to sacrifice readability and type safety to go from
poor to acceptable performance (that is, still far from excellent) ?
Maybe Lua is simply not the right tool, at least not to do the actual
computations. On the other hand I could probably use it to describe the
computation and generate an equivalent C code compiled on the fly.