Re: Lua Test Code (and a C# porting question)

[Mark Feldman <mfeldman@...>]

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.