[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: lua in high performance apps
- From: "Joshua Jensen" <jjensen@...>
- Date: Mon, 16 Apr 2001 21:15:55 -0600
> > > 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/