thoughts on Lua 5.2 for eLua

classic Classic list List threaded Threaded
7 messages Options
King, Mike King, Mike
Reply | Threaded
Open this post in threaded view
|

thoughts on Lua 5.2 for eLua

Are there any plans on using Lua 5.2 at some point?  The following changes look interesting for eLua.

- yieldable pcall and metamethods
- new library for bitwise operations
- light C functions
- emergency garbage collector
- no more verification of opcode consistency
- simpler implementation for string buffers
- parser uses much less C-stack space (no more auto arrays)
- generational mode for garbage collection (experimental)

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited.
If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s).

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Dado Sutter Dado Sutter
Reply | Threaded
Open this post in threaded view
|

Re: thoughts on Lua 5.2 for eLua



On Tue, Feb 8, 2011 at 16:23, King, Mike <[hidden email]> wrote:
Are there any plans on using Lua 5.2 at some point?

Yes, sometime in the future (and not before Lua 5.2 itself is launched :)
 
 The following changes look interesting for eLua.

- yieldable pcall and metamethods
- new library for bitwise operations

Yes. We've added a bit lib but last weekend I missed some features too. Lua 5.2 will have it natively but I'm afraid we'll have to extend it again for embedded-specific uses. But this is where the Lua fun is ! :)

- light C functions

You mean without meta-tables or romable functions (that we already have) ?
 
- emergency garbage collector

eLua has this since v0.7
 
- no more verification of opcode consistency

To gain speed or space (or both) ?
Lua is very robust and opcode consistency check is one of the reasons. It's a self-contained language, in that all the errors are explained by Lua itself. I'm not sure if the footprint gain or even the performance would justify loosing it. But yes, it is worth checking, for sure.

- simpler implementation for string buffers

I thought that Lua's implementation was one of the simplests possibles. What would we gain here ?
 
- parser uses much less C-stack space (no more auto arrays) 
- generational mode for garbage collection (experimental)

Nice (==it sounds hard to me but brains here know how to do it :)

We will have a public roadmap one of these days and it will be nice to refine it with this kind of collaboration. Thanks !!!

Best
Dado







CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited.
If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s).

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
King, Mike King, Mike
Reply | Threaded
Open this post in threaded view
|

Re: thoughts on Lua 5.2 for eLua

>>The following changes look interesting for eLua.

>>- yieldable pcall and metamethods
>>- new library for bitwise operations

>Yes. We've added a bit lib but last weekend I missed some features too. Lua 5.2 will have it
>natively but I'm afraid we'll have to extend it again for embedded-specific uses. But this is where
>the Lua fun is ! :)

Will the yieldable pcall and metamethods be useful for threading?

>>- light C functions

>You mean without meta-tables or romable functions (that we already have) ?

I know the LTR patch reduces the RAM footprint, but would there be an advantage to move closer to the Lua codebase?  In other words to have a small patch.
 
>>- emergency garbage collector

>eLua has this since v0.7

Is it the same code?
 
>>- no more verification of opcode consistency

>To gain speed or space (or both) ?
>Lua is very robust and opcode consistency check is one of the reasons. It's a self-contained
>language, in that all the errors are explained by Lua itself. I'm not sure if the footprint gain or even
>the performance would justify loosing it. But yes, it is worth checking, for sure.

Okay

>>- simpler implementation for string buffers

>I thought that Lua's implementation was one of the simplests possibles. What would we gain here ?

It appears the C API now has a new function (luaL_buffinitsize) which allows one to set the final size of the buffer.
 
>>- parser uses much less C-stack space (no more auto arrays) 
>>- generational mode for garbage collection (experimental)

>Nice (==it sounds hard to me but brains here know how to do it :)

> We will have a public roadmap one of these days and it will be nice to refine it with this kind of collaboration. Thanks !!!

>Best
>Dado







CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited.
If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s).

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: thoughts on Lua 5.2 for eLua

In reply to this post by King, Mike
Hi,

> Are there any plans on using Lua 5.2 at some point?  The following changes look interesting for eLua.

It's not on the roadmap yet. The plan (at least my plan) was to wait
for the official 5.2 to be released and then allow some time for it to
become more wide spread and to interpret the associated feedback.
Personally the only good reason I see right now to move to Lua 5.2 is
that the rest of the world is going to do it eventually.

> - yieldable pcall and metamethods

If you really need this you can get it with the coco patch that was
already ported to eLua on a separate branch.

> - new library for bitwise operations

You already have bit. in eLua. Also I'm planning to integrate a patch
that would make bitwise operations accesible directly from the
language (without the need to use a separate module) simply because it
makes sense on embedded.

> - light C functions

We have that with the LTR patch. And we have much more than that:
light tables (they're called 'rotables'). Together with light function
they allow a C module written for Lua to consume exactly 0 bytes of
RAM memory when registering to Lua. Adapting the LTR to Lua 5.2 will
be one quite difficult task.

> - emergency garbage collector

We have that thanks to Robert Jakabosky.

> - no more verification of opcode consistency

I don't think this makes a significant impact on the speed/size of the
code. I do remember some discussions about this on the Lua list but I
don't remember the conclusions :)

> - simpler implementation for string buffers

Same as above: no idea about the impact.

> - parser uses much less C-stack space (no more auto arrays)

eLua already addresses this with some parser-related patches. I'll
have to check against the 5.2 distro at some point to see what are the
differences between my (quite ad-hoc) patches and their
implementation. Having the parser use the heap instead of the stack is
a Very Good Thing. Stack overflow errors are a pain to debug.

> - generational mode for garbage collection (experimental)

My knowledge about garbage collectors is very limited; consequently, I
have no idea what the actual impact of this would be. I'd love to hear
the oppinion of someone with more expertise in this area.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Dado Sutter Dado Sutter
Reply | Threaded
Open this post in threaded view
|

Re: thoughts on Lua 5.2 for eLua

In reply to this post by King, Mike


On Tue, Feb 8, 2011 at 17:04, King, Mike <[hidden email]> wrote:
>>The following changes look interesting for eLua.

>>- yieldable pcall and metamethods
>>- new library for bitwise operations

>Yes. We've added a bit lib but last weekend I missed some features too. Lua 5.2 will have it
>natively but I'm afraid we'll have to extend it again for embedded-specific uses. But this is where
>the Lua fun is ! :)

Will the yieldable pcall and metamethods be useful for threading?

>>- light C functions

>You mean without meta-tables or romable functions (that we already have) ?

I know the LTR patch reduces the RAM footprint, but would there be an advantage to move closer to the Lua codebase?  In other words to have a small patch.
 
>>- emergency garbage collector

>eLua has this since v0.7

Is it the same code?
 
>>- no more verification of opcode consistency

>To gain speed or space (or both) ?
>Lua is very robust and opcode consistency check is one of the reasons. It's a self-contained
>language, in that all the errors are explained by Lua itself. I'm not sure if the footprint gain or even
>the performance would justify loosing it. But yes, it is worth checking, for sure.

Okay

>>- simpler implementation for string buffers

>I thought that Lua's implementation was one of the simplests possibles. What would we gain here ?

It appears the C API now has a new function (luaL_buffinitsize) which allows one to set the final size of the buffer.

Thanks! Is it a 5.2 feature ? I'll check ...
I'm not sure if I understood the benefits but these would be restricted to fixed or known maximum-sizes string operations right ?
Surely interesting for embedded apps but a bit hard to explain to regular Lua users right ?

 
>>- parser uses much less C-stack space (no more auto arrays) 
>>- generational mode for garbage collection (experimental)

>Nice (==it sounds hard to me but brains here know how to do it :)

> We will have a public roadmap one of these days and it will be nice to refine it with this kind of collaboration. Thanks !!!

>Best
>Dado


Sorry for the hurry
Thanks!
Best
Dado




 






CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited.
If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s).

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
King, Mike King, Mike
Reply | Threaded
Open this post in threaded view
|

Re: thoughts on Lua 5.2 for eLua

>>>>- simpler implementation for string buffers

>>>I thought that Lua's implementation was one of the simplests possible.
>>>What would we gain here ?

>>It appears the C API now has a new function (luaL_buffinitsize) which allows
>>one to set the final size of the buffer.

>Thanks! Is it a 5.2 feature ? I'll check ...
>I'm not sure if I understood the benefits but these would be restricted to
>fixed or known maximum-sizes string operations right ?
>Surely interesting for embedded apps but a bit hard to explain to regular
>Lua users right ?

I've looked at the Lua 5.1 buffer code in the past and it clearly inefficient.  Someone on the mailing list explained the reason.  It had something to do with it only using the public API.

I haven't looked at the code yet, but I know the algorithm could be improved (no concats) if it knew the final size.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited.
If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s).

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Vaughan McAlley-2 Vaughan McAlley-2
Reply | Threaded
Open this post in threaded view
|

Re: thoughts on Lua 5.2 for eLua

On 9 February 2011 08:58, King, Mike <[hidden email]> wrote:

>>>>>- simpler implementation for string buffers
>
>>>>I thought that Lua's implementation was one of the simplests possible.
>>>>What would we gain here ?
>
>>>It appears the C API now has a new function (luaL_buffinitsize) which allows
>>>one to set the final size of the buffer.
>
>>Thanks! Is it a 5.2 feature ? I'll check ...
>>I'm not sure if I understood the benefits but these would be restricted to
>>fixed or known maximum-sizes string operations right ?
>>Surely interesting for embedded apps but a bit hard to explain to regular
>>Lua users right ?
>
> I've looked at the Lua 5.1 buffer code in the past and it clearly inefficient.  Someone on the mailing list explained the reason.  It had something to do with it only using the public API.
>
> I haven't looked at the code yet, but I know the algorithm could be improved (no concats) if it knew the final size.
>

In Lua 5.1 I believe strings were added to the buffer character by
character. In 5.2, if it knows it’s adding 1000 characters or whatever
(eg table.concat), it grows the buffer (which is an ordinary userdata)
by 1000 and does a memcpy. So it’s not checking whether it needs to
grow the buffer every time a character is added.

So even though Lua 5.1 was fast with strings this probably represents
a performance improvement.

Vaughan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev