lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Roberto Ierusalimschy wrote:
>> a standard set of samples that each release of the Lua source code is
> See http://lua-users.org/lists/lua-l/2008-06/msg00124.html

Perfect, thanks! My port currently runs the majority of those tests properly but I still have some work to do. (I haven't tried your code yet François but thanks for the pointer to it.)

One of the things I would like some feedback on is what people think the priorities should be when porting Lua to other languages. When I started my port it quickly became apparent that there were going to have to be some compromises between behaviour, code maintainability and performance.

Behaviour is a tricky one, I don't think it's possible to do an exact C# port given the disparities even across existing compiler environments. As an example, I've had to port the garbage collector code as well in order for things like weak tables to behave as closely as possible to the way they do with the original code (although the actual disposing is still handled by the .NET CLR). The Lua GC needs to be able to calculate the size of various structures in order to keep track of memory allocation, but it's difficult/impossible to obtain those in managed C#. I got around it by simply hard-coding the size of all the counterpart Win32 C++ structures and setting the VM's memory management routines to use those for its bookeeping. It works, but can potentially change the behaviour of other parts of the code e.g. global_State.totalbytes is now more of a hueristic for the GC rather than a true indication of current memory allocation.

After behaviour, my secondary objective has been code maintainability...I've generally kept the port line-by-line as close to the original code as possible so that future patches and upgrades can be easily applied. Unfortunately this strategy seriously affects performance, even with full optimizations enabled. The original code makes judiscious use of the template processor and since C# doesn't have a preprocessor these have had to be replaced with static internal/private member functions, which is exactly what you don't want in the type of performance-critical code that it's being used for. Sometimes the C# optimizer performs well, often it doesn't!

Lua's performance is arguably one of its main attractions, but my philosophy so far has been to get the behaviour to match the original code as closely as possible and try to deal with performance optimization later. Is this the preferable strategy to take with Lua ports in general, or should duplicating the exact behaviour of the VM take more of a back seat?

Mark Feldman


This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.