RE: Ideas for faster math in lua

[Diego Nehab <diego@...>]

Hi,

> > 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) ?

Readability: Not suggesting that at all. I am just following
your premises. The syntax you said you tried is heavier than
the one I suggested. If these functions return the l-value,
you can even nest them.

I thought there were a few optimization strategies that you
had not considered. I am trying to help by pointing them
out. Locals do make a difference in tight loops. I has been
pointed out in this list before.

Safety: Not suggesting that either. Just saying that you can
use a single table lookup for type safety, instead of
getting a metatable from the object, another from the
registry (keyed by a string!), and comparing them. You could
use a weakly keyed table of valid light userdata, keyed by
their values, and store it as an upvalue to the functions
that need to do error checking. Error checking would reduce
to one table lookup (keyed by something easier to hash) and
a isnil check.

I don't know how much faster that would be, but I am using
this strategy in the new version of LuaSocket. Very clean,
very simple, totally safe.

> 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.

I agree 100% with this. And I would love Lua to be able to
optimize temporary userdata creation on the stack, as well
as overwritting l-values instead of creating a new one. I
have not come up with a clean way of specifying this
behavior. If any of us do, please share.

Finally, have you tried using LuaJIT? I know nothing about
it, but maybe the function call overhead magically
disappears?

Regards,
Diego