Too LuaJIT to quit

I’ve been happily trundling along with Lua these past few months, and gotten a fair bit of experience with it.  Before using Lua, I was a hard core C# zealot.  I have a github repository of a ton of C# stuff that I’ve done in the past.  A huge bulk of that library of stuff is interop calls to other parts of Windows, OpenGL, and various other obscure libraries that will never have formal .net framework support.

I love C# as a language.  Really I love well done garbage collection, otherwise, it’s just another in a long line of ‘C’ inspired languages.

One thing I find particularly challenging with C# is that there isn’t always an interop library available for the latest and greatest cool thing.  Nowadays, invariably it will show up, but still, not always.  For example, the very first attempts at interop with a Kinect were not using C#.  In addition, C# is limited in that it is not really native to all platforms on the planet.

So, what about Lua?  Well, Lua, although it works fairly nicely with C interop, is a bit much to deal with.  In order to write a simple wrapper might require quite a few likely error prone steps.  The state of things is such that it’s best done using a tool, such as tolua, or tolua++.  These tools will invariably write a bit of C code that wraps the library call in question with some  more goo, dealing with marshalling parameters if necessary, and the like.

Then, along comes LuaJIT.  There are a number of good things about LuaJIT.  One of the most important is that it runs much faster than the standard Lua distribution.  In some cases, the code runs as fast as standard compiled C code does.  At the very least, I believe it runs faster than any of the other scripting language environments, including the V8 processor for JavaScript.

The thing that got me to look at it though was not just the speed, although that’s a great bonus.  The other thing is the easier interop to libraries.  With LuaJIT, there is this FFI technology that allows you to make library calls by doing nothing more than taking the standard C definitions of those functions and putting them within some brackets.  The LuaJIT parser can read the standard C declaratons, and generate the appropriate stub call, do the marshalling of parameters, and all that stuff.

Well gee!  That’s just a godsend.  I was really dreading having to write all that wrapper good, bloating my code in the process.  With LuaJIT, I don’t have to.  I just need to make sure my declarations are exactly right, and then make calls to functions almost as easily as if they were just Lua calls.

Another bonus is the easy treatment of structure types.  You can use the familiar:

typedef struct { int x,y;} POINT;

And that works just fine.  Similarly, if you want to create an array of rgb pixels: typedef struct {byte r,g,b;} pixel_rgb

And you’re all set.  This latter one is useful if you’re doing any rendering, because from Lua I can now do “direct access” to stuff, like I do in C, although there is still managed memory safety.  This reduces the memory footprint of my code, and speeds things up dramatically, particularly when I’m transferring from a pixel buffer to a texture object for display on the screen.

LuaJIT is a departure from the normal Lua distribution, which just recently had a release.  I for one welcome the departure.  It allows for much more flexibility in how to do things.

One thing that I discovered as I was trying out LuaJIT.  The first library I connected to was the gdi32.dll on Windows.  I wanted to get a device context for the screen, and then draw lines, ellipse, and rectangles.  Easy enough.  I did discover something along the way though.  I thought Rectangle() would be really fast, hardware accelerated goodness.  As it turns out, it took many seconds to draw a few hundred on the screen.  I thought that was rather odd, so I tried out RoundedRect() to see how much worse that was going to perform.  Given the same number of rectangles, it displayed in the blink of an eye!  Go figure.  I guess somewhere in the graphics pipeline, rounded rectangles got optimized, and straight ones did not.  that’s a good fact to know.

One thing that makes this interesting to me is the ease with which this little experiment can be achieved.  Since it’s Lua, it’s a small matter of script to get things going.  There is no explicit “compile” phase.  Just write a little script and run it, and see what happens.

Given the speed, the interop capabilities, and the general ease of use of Lua, I’m wondering if I ever really need to use anything else to do system type programming.  I did write all those libraries in C#, but maintaining, and extending them is quite a chore, an art and science, and a generally error prone activity to get them absolutely right.

The next thing I’ll try, after finishing up some more of GDI and User32, is hook up the USB port functions to see how hard it will be to Kinect.

 

Advertisements

2 Comments on “Too LuaJIT to quit”

  1. Dave Lannan says:

    Hi, I’d like to also give the thumbs up to the LuaJIT system – have been using Lua since 2002 and its a lovely _simple_ language to use. LuaJIT + FFI is like the icing on the cake, speed + flexibility 🙂

    I know this article is a bit old now.. hope you are still working with LuaJIT. I have been working on a OpenGLES interface for phones, and pc’s. Just to make dev life easy.
    Cheers,
    Dave

    • Yes, still working with LuaJIT. I’ve done a number of other articles since this one. The current version of LuaJIT has improvements in the FFI which make it even easier to use as a replacement for typical C/C++ code.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s