[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Test Code (and a C# porting question)
- From: Mark Feldman <mfeldman@...>
- Date: Wed, 30 Sep 2009 14:32:28 +1000
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
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?
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.