RE: Ideas for faster math in lua

[Diego Nehab <diego@...>]

Hi,

> I initialy posted to signal I met the same problems as the
> original poster, but actually I gave up Lua level
> optimizations some time ago.  However I'm still interested
> in the discussion and your help is welcome :-)

And I am always interested in benchmark results that 
update me on what is fast and what is not fast. Since I have
been lazy to run my own benchmarks, I thought I had a 
shot at getting someone else to try these things for me. :)

> > 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.
>
> Correct me if I'm wrong, but the trade is one getmetatable
> (which afaik is not a table lookup), one table lookup (the
> type metatable from the registry) and a rawequal for my
> current method, versus two table lookups (the weak table
> from the registry and the object inside the weektable) and
> a isnil. I can believe there's a gain but it's not
> obvious. Or maybe I missed something.

There is only one table lookup. The weak table is not in the
registry, it is an upvalue to rotate/translate/copy.
Upvalues should be pretty fast. Plus, the table lookup that
actually happens uses a lightuserdata as the key. The
luaL_checkudata function uses a full string, not even a literal
string.  I think the string has to be traversed for its length,
hashed, and compared, perhaps even allocated if not found. The
lightuserdata is just a pointer, so I expect the lookup to
be much faster.  Then again, I haven't measured the gains yet
(but at some point I will).

> > 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.
>
> Is that in the last released version of in one about to be
> released ?

Neither. On the one that is not quite about to be released:
LuaSocket 3.0 (I know, it is taking forever).  LuaSocket
objects use the method syntactic sugar and must be
finalized, which requires a metatable.  Therefore I can't
simply lightuserdata for the sockets.  Maybe there is a way,
but it has not occured to me yet. Perhaps using environments
for the methods, and an associated full userdata for
finalization (using the same weakly-keyed table trick to
associate).  Lightuserdata cannot have environments,
though...  I don't know why. Dead-lock.

LuaSocket 3.0, however, has many uses for lightuserdata,
hence the idea. Even for objects with metatable, the idea of
using a lightuserdata as key to the table with classes
(instead of a string with the class name, use a pointer to a
static string, pushed as lightuserdata) and of using an
upvalue instead of the registry might still be worth it.  So
I may backport these to LuaSocket 2.x.

Kind regards,
Diego