RE: report on the Lua in the Gaming Industry Roundtable at GDC 2004

["Jasmin Patry" <jpatry@...>]

We do a fair amount of per-frame Lua processing, and have found significant speedups by grouping together as much Lua processing together as possible.  For example, on of our systems uses "Lua conditions" (boolean-valued functions) to determine if the system should change state.  Instead of calling each condition chunk separately from C++, we found it much faster to call one big Lua function that calls the condition functions (and returns the index of the first one to return true).  For one state with about 40 Lua conditions, this gave us roughly a 10x speedup.

My *guess* is that the one-big-Lua-function approach has much fewer cache misses, and that this is largely responsible for this performance improvement.  I should also note that this was on the PS2, where cache misses hurt dearly.

Jasmin


-----Original Message-----
From: Adam D. Moss [mailto:adam@gimp.org]
Sent: Thursday, April 15, 2004 12:56 PM
To: Lua list
Subject: Re: report on the Lua in the Gaming Industry Roundtable at GDC
2004



>    Avoid  using  Lua  in  "every  frame"  actions  as  performance  drops
>    dramatically.  For example, don't use Lua to do animation updates; set
>    up  parameters  for  the  animation in Lua and do the updates in C/C++
>    code.

Yes!!  I wish I'd had someone warn me six months ago.  :)  I'm
still not sure why Lua seems to perform very respectably for
reactive tasks and even a lot of general-purpose crunching but
REALLY starts to drag when doing even a few rather simple
tasks /every/ frame.  Perhaps the setup of invoking Lua from C
is fairly heavy (I suspect not) or it's a more subtle issue
such as Lua thrashing the memory caches.

I love and use Lua, but I'm in the middle of some rearchitecting
at the moment because I discovered the above truism the hard
way pretty late. :)

--Adam
-- 
Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3