Re: lua in high performance apps

["Joshua Jensen" <jjensen@...>]

As a followup to this, I should also mention that I use Lua for a lot of
algorithm prototyping, since the scripts can be reloaded on the fly.  I
would guess the majority of the time, the code is later moved to C/C++ for
speed.

Thanks,
Joshua Jensen
Author, Workspace Whiz! - A Visual Studio Add-in
http://workspacewhiz.com/

> > > > Has anyone here used lua in what might be a considered a
long-running
> > > > high performance app?
> > > > For example, has anyone used lua for the AI of a real time strategy
> game
> > > > with lua programs controlling each of a hundred or more units, 30
> times
> > > > a second?
> > >
> > > I had every intention to, but came to the conclusion that it isn't
> > practical
> > > without the support of an incremental garbage collector.  The games
that
> > Lua
> > > has been used in are non-real time from what I can tell.
> >
> > Th AI in RTS games is not usually executed every frame.  The AI is
> generally
> > updated every ten frames or so or spread out over a couple of frames.
So
> > it's still real-time, but a slower form of real-time.
>
> I've used Lua in real-time apps (read: games) with great success, but only
> if I profile and understand where the bottlenecks in the Lua script are.
>
> These are some optimization strategies I use (off the top of my head):
>
> 1) Local variables are very quick, since they are accessed by index.  If
> possible, make global variables local (weird, eh?).  Seriously, it works
> great and indexed access is always going to be faster than a hash lookup.
> If a variable, say GameState, needs global scope for access from C, make a
> secondary variable that looks like 'local GSLocal = GameState' and use
> GSLocal within the module.  This technique can also be used for functions
> that are called repetitively, too.
> 2) for loops are quite a bit faster than while loops, since they have
> specialized virtual machine instructions.
> 3) In your C callback functions, use lua_rawcall() to call other
functions.
> The overhead of a setjmp() call for exceptions (and a few other things) is
> avoided.  I would not recommend using lua_rawcall() outside of a callback
in
> case something goes wrong during execution.  Without the setjmp() call,
the
> error handler that exits the application is called.
> 4) If possible, in your C functions, try and use lua_rawget() and
> lua_rawgeti() for table access, since it avoids the tag method checks.  Be
> sure to use lua_rawgeti() for indexed access.  It's still a hash lookup,
but
> it's probably the fastest way to get there by index.
> 5) In C, use lua_ref() wherever possible.  lua_ref() behaves similarly to
a
> local variable in terms of speed.
> 6) Know that C strings passed into a Lua function (such as
lua_getglobal())
> from C are translated to a Lua string on entry.  If a string is to be
reused
> across multiple frames of the game, do a lua_ref() operation on it, too.
>
> Above all, trace the virtual machine.  Know what it is doing.  I find
that,
> on average, Lua executes around 20 times slower than C (depending on the
> operation, of course).  Use the C callbacks to your advantage in this
> scenario, so Lua acts as glue and you can take advantage of a cool
scripting
> language.
>
> Thanks!
>
> Joshua Jensen
> Author, Workspace Whiz! - A Visual Studio Add-in
> http://workspacewhiz.com/
>
>
>