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

[Edgar Toernig <froese@...>]

Dario Accornero wrote:
>
> On 16 Apr 2004, at 1:12, Ashwin Hirschi wrote:
> 
> > I think another reason might be that a Lua-C/C++-Lua transition is 
> > relatively expensive. So reducing the number of Lua calls to a C++/C 
> > engine, like your calling everything in one go approach, will be 
> > cheaper. Though I'm not sure exactly how big the savings are in 
> > real-world examples...
> 
> I have a gdb window open right now, and here's what I see:
> 
> 0. my C++ code				[breakpoint here]
> 1. Lunar<myclass>::thunk
> 2. luaD_precall
> 3. luaV_execute
> 4. luaD_call
> 5. f_call
> 6. luaD_rawrunprotected
> 7. luaD_pcall
> 8. lua_pcall
> 9. Lunar<myclass>::call
> 
> The Lunar calls represent the price I pay for using this particular 
> interface, and I'm fine with that.  On the other hand, the seven stack 
> frames required in any case to reach my own code look quite expensive 
> indeed.

The C<->Lua transition is normally cheap.  Not very different from a
function call within Lua.  But what *could* be expensive is lua_pcall.
The problem with lua_pcall is that it uses setjmp/longjmp which
performs a system call on some systems (those which preserve signal
masks).  You could either try _setjmp/_longjmp instead or use lua_call
and catch errors elsewhere (may become difficult with C++).
Additionally, lua_call instead of lua_pcall would remove stack frames
5, 6, and 7 from the above trace.

Ciao, ET.

PS: The cache miss argument mentioned earlier is not to be discarded
lightly.  On current systems, a cache miss may cost from several 100
to some 1000 clock cycles.  The ratio between CPU speed and memory
bandwidth has become that big that nowadays execution speed is no
longer dominated by the number of instructions required to perform
a specific task.