Re: Next Version of Lua?

[Niklas Frykholm <niklas@...>]

Yes, I know I've kind of reached a dead-end with lua 5.1 where none of
the options is really attractive (userdata generating lots of garbage,
increased TValue size inflating memory use, manual memory management
in pools which is hard to use). That's why I brought this up in a
thread discussing future changes to Lua. To say that this is something
that I'm missing.

C# has "structs" -- a variable-sized value type.

I'm not sure if variable sized value types are right for Lua. It might
be it requires so many choices to the core it destroys the attractive
simpleness of the language. It might be that these performance issues
would be better addressed with a fast and smart generational garbage
collector. It might also be that nobody but me cares about this
particular performance issue.

// Niklas


2009/6/11 Asko Kauppi <askok@dnainternet.net>:
>
> Well... Do you think you can both eat and save the pie?  :/
>
> Seriously, only the string type of the built-ins allows for variable length.
> If you don't want to grow Value, you'll need to do something similar to
> string. I bet it will make them immutable, as strings are.
>
> So why not just use strings to store the 3D values?  As binaries.  You'll
> make C side code to create them of course:
>
>        local v= vec3d( 0.123, 1.234, 2.345 )
>        print( v.x, v.y, v.z )          -- cannot be done since it's a string
>        print( v )                              -- would give binary garbage
>
> And you cannot override add and sub and mul and... either.   Meaning you
> want userdata.
>
> Case closed?  :))
>
>
> Niklas Frykholm kirjoitti 11.6.2009 kello 12:30:
>
>> Yes, that would work and wouldn't be too tricky. The drawback is that
>> you would have to increase the size of the Value union to have room
>> for the biggest value type you wanted to support. Support for Vector3
>> would triple the size of Value and double the size of TValue. Which
>> would mean close to doubling the memory footprint of a running lua
>> application.
>>
>> I'm targetting game consoles, where increasing the script memory from
>> 30 MB to 50 MB or even 40 MB is a big deal... so I can't really go
>> that path.
>>
>> // Niklas
>>
>> 2009/6/10 Asko Kauppi <askok@dnainternet.net>:
>>>
>>> About the complex type, LNUM patch allows all Lua numbers to be complex
>>> (compile with LNUM_COMPLEX defined; C99 required for C complex support).
>>>
>>> The approach could of course be extended to making a native 3D vector
>>> datatype, as well.
>>>
>>> -asko
>>>
>>>
>>> Niklas Frykholm kirjoitti 10.6.2009 kello 17:42:
>>>
>>>> 2009/6/10 Duncan Cross <duncan.cross@gmail.com>:
>>>>>
>>>>> On Wed, Jun 10, 2009 at 2:55 PM, Niklas Frykholm<niklas@frykholm.se>
>>>>> wrote:
>>>>>>
>>>>>> 2009/6/10 Olivier Hamel <evilpineapple@cox.net>:
>>>>>> Currently, if you want to create Complex or Vector3 type you have to
>>>>>> do it as a table or a userdata. And if you do a serious ammount of
>>>>>> processing on them, the ammount of garbage generated by simple
>>>>>> arithmetic operations will soon put a significant strain on the
>>>>>> system. (You could use a pool of such objects, but that would mean
>>>>>> resorting to manual memory management with all its pains - especially
>>>>>> when you are using it for something as simple as numbers.)
>>>>>
>>>>> Perhaps I am misunderstanding, but if the pool is a table that has
>>>>> been set to have weak values (i.e. its metatable's __mode field is set
>>>>> to 'v'), you should not have to do any manual memory management -
>>>>> values that only exist in the pool will be eligible for garbage
>>>>> collection.
>>>>
>>>> My description was a bit short, but the whole point of having a pool
>>>> was to avoid generating garbage. (By using a free object from the
>>>> pool, rather than creating a new one, whenever a new object is
>>>> needed.) But this requires us to manually track which objects in the
>>>> pool are free or not (i.e., manual memory management).
>>>>
>>>> If the objects in the pool are eligible for garbage collection, then
>>>> the pool doesn't really buy us anything. We will generate the same
>>>> ammount of garbage with the pool as without it.
>>>>
>>>> // Niklas
>>>
>>>
>
>