Re: Fast metamethods for Userdata types

[Dibyendu Majumdar <mobile@...>]

On 7 April 2015 at 07:14, Sean Conner <sean@conman.org> wrote:
>> Apologies if this is going over old ground ... I have been thinking
>> about how to allow fast metamethods for userdata objects. As userdata
>> objects are created by C code then it is possible for C code to
>> provide an array of C functions (like a C++ vtable) for the userdata
>> object - the C functions to be used as metamethods.
>>
>> What would be reason for not doing it this way?
>
>   I assume you are talking about functions like __add() or __concat().

Yes but more importantly __index method.

>   Also, metatables are used to provide functions (or fields) other than the
> defined metamethod ones.  For instance, the metatable for io.stdout (again,
> Lua 5.3):
>
> __tostring  function: 0x8060888
> flush       function: 0x8061a00
> lines       function: 0x8060df0
> __name      "FILE*"
> seek        function: 0x80618a8
> write       function: 0x8061870
> setvbuf     function: 0x8061960
> __gc        function: 0x80609d8
> __index     table: 0x9654428
> close       function: 0x806098c
> read        function: 0x80615cc
>
>   The metatable is a nice place to cache all this.

Right - but isn't that even worse for performance - i.e. more chances
of hash collision?

>> I am interested in this as I want to achieve high performance for
>> certain operations involving userdata types - which otherwise means I
>> have to make the VM recognize these types so that it can perform
>> operations on these types natively. However that approach isn't
>> scalable as enhancing the VM to recognize new types is a lot of work.
>
>   What type of high performance are you expecting?  Outside of numbers and
> strings, trying to get high performance out of metamethods with userdata
> just doesn't seem to make sense to me.  LPeg is perhaps the worse-case
> scenario here (which to me, makes it the best place to start) as the '*'
> operator isn't multiplcation (it's more of an "and" operation but not
> commutative).

I am thinking of structures such as vectors and matrices. Agree that
__add() probably doesn't matter so much as the addition itself will be
expensive. But performance of __index matters. Now if you think of
Ravi where the [] operator on an array is specialized - and executed
inline for gets, then the cost of a hash table lookup and then going
through the mechanism for a function call is enormous. I will try to
do a benchmark at some point to investigate how much performance loss
really occurs but my guess is that it is not insignificant.

Of course even if a C vtable could be provided that only saves the
cost of hash table lookup so the other cost is still there so in the
end the gains would be small, so I also think a generic solution is
hard.

I believe (reading the paper on evolution of Lua) that the current
approach is chosen for its simplicity and the fact that it reuses the
table infrastructure, but I could be wrong.

Regards
Dibyendu