[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Fast metamethods for Userdata types
- From: Dibyendu Majumdar <mobile@...>
- Date: Tue, 7 Apr 2015 21:50:54 +0100
On 7 April 2015 at 07:14, Sean Conner <email@example.com> 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
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
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.