RE: extended lua value type question

Hey

Main problem with userdata is that this is about being as fast as is humanly possible! Most stuff is easy to say ‘avoid this expensive thing’, but when a simple vector operation like a = b*10+c actually evaluates to reading a vector, multiplying it by ten, allocating a new vector with the result, loading another one, adding the 2 together, allocating another one for the result and storing in a, it’s very easy to inadvertently create a lot of allocations/frees of user data (this is indeed what we were doing before and it was a real hit to performance). On testing, the principle cost came from the allocation of vectors from the heap (and freeing them during garbage collection) which is naturally not massively fast. We have to compare all this stuff to the general cost of the actual vector operations themselves – metatable lookups and heap allocation take an order of magnitude longer than the actual vector op itself! However, using a block allocator that avoids heap allocations, and building some of the operations into the vm rather than resorting to metatable lookups and function calls is far more efficient.

So short version, it is solely to do with performance. With the vector maths, every cycle counts so anything that chips away at their cost is a big win overall.

-Chris

From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Andrew Starks
Sent: 11 November 2014 19:55
To: Lua mailing list
Subject: Re: extended lua value type question

On Tue, Nov 11, 2014 at 12:59 PM, Tim Hill <drtimhill@gmail.com> wrote:

> On Nov 11, 2014, at 6:33 AM, Chris Cummings <chrisc@mediamolecule.com> wrote:
>
> Hmmm - you know what, after more thought I reckon you guys a right - I reckon I'll have to make vectors reference types, even if I do end up making some modifications to the LUA libraries to make allocating/freeing them faster. Relying on the compiler not to have made (valid) assumptions about the behaviour of settable seems too risky.
>
> Has anyone any experience/examples of adding new types of garbage collectable objects (crucially ones that use their own approach to memory allocation/freeing)?
>
> -Chris
>

If you are going with reference types then why not just use a full userdata? This gives you GC behavior and metatables, which should be enough to allow you to deeply integrate your new type into the system (for example, “a + b” semantics for vectors). All you really need to do is wrap type() so that it can return new strings for your userdata types and they are pretty much first class reference types.

—Tim

I think he's moved on, but it looked like he was trying to solve the problem where:

myvec = vec{x = 1, y=2}

func1(myvec)

func2(myvec)

somewhere inside of func1:

myvec.x = 3

now func2's myvec has changed and he didn't want them to change, outside of func1.

But I don't believe that these semantics can be made to work as he had hoped, without pass-by-value for this object. I can't even think of how you could do that, even if you were to go crazy with it...

-Andrew