[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Fast metamethods for Userdata types
- From: Rena <hyperhacker@...>
- Date: Tue, 7 Apr 2015 18:43:29 -0400
On Tue, Apr 7, 2015 at 2:14 AM, Sean Conner <firstname.lastname@example.org> wrote:
> It was thus said that the Great Dibyendu Majumdar once stated:
>> 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().
> Well, not all metamethods are functions. __mode, __metatable and __name
> (Lua 5.3) are never functions, while __index and __newindex can either be a
> function or a table. Most, however, are functions .
> For insance, "x = lpeg.P(1)" has the following metatable:
> __mul function: 0x77adf8
> __add function: 0x77ad08
> __pow function: 0x77ab04
> __div function: 0x77a8c8
> __name "lpeg-pattern"
> __unm function: 0x77a84c
> __gc function: 0x77b384
> __index table: 0x9664278
> __sub function: 0x77a6e8
> __len function: 0x77aa94
> __index could just as easily have been a function (maybe not for LPeg but in
> the general case).
> 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.
>> 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 suppose you might see some performance gain (at the cost of memory)
by having an array associated with each userdata, which stores
pointers to C functions for each metamethod at particular indexes.
(e.g. metamethods is __index, metamethods is __newindex, etc.)
If the pointer is NULL, then you look in the metatable. That would be
something Lua could manage internally when you set or modify the
Someone would have to try it and see if there's any significant
performance gain. It could be implemented as a compile-time option.
Sent from my Game Boy.