thoughts on Lua 5.2 for eLua
Locked
|
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 |
|
|
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. 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
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
>>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 |
|
|
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 |
|
|
In reply to this post by King, Mike
On Tue, Feb 8, 2011 at 17:04, King, Mike <[hidden email]> wrote:
http://www.eluaproject.net/en_elua_egc.html http://www.eluaproject.net/en_refman_gen_elua.html#elua.egc_setup http://www.eluaproject.net/en_building.html#static
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 ?
Sorry for the hurry Thanks! Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
>>>>- 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 |
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 |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |