Re: Question about LuaJIT's future FFI/Struct Extension

[Colin <colin.hch@...>]

On Thu, Mar 18, 2010 at 9:52 AM, Pavel Holejsovsky
<pavel.holejsovsky@upek.com> wrote:
> On 3/17/2010 8:57 PM, Mike Pall wrote:
>>
>> Peter Cawley wrote:
>>>
>>> Along the same lines, I noticed that in a recent project, most of my
>>> C(++) glue functions did very simple things - read some values off the
>>> Lua stack, call some C++ method, and push the results back onto the
>>> stack. It seems to me rather wasteful for LuaJIT to setup a stack,
>>> call my C(++) function, have that call back to the API to read/write
>>> values, then have LuaJIT tear the stack down again.
>>
>> Yes, now that everything else has gotten so fast, that's the main
>> performance bottleneck when calling C functions from compiled Lua
>> code. And it gets worse: the compiler can't optimize across such
>> calls, because they might have arbitrary side-effects (changing a
>> global, growing/reallocating a table etc.).
>
> Maybe for beginning it would be nice to have possibility to mark luCFunction
> as 'does not touch Lua state at all', therefore having no LuaJIT-visible
> side effects.  This would mean that trace recording would not be aborted if
> such call is met.  I think that this could speed up things if such calls are
> met inside hot loops (e.g. lua loop processing data from
> externally-allocated memory block).

Absolutely...

...and then offer a simplified interface, that gives LuaJIT more
freedom, for functions that are "pure" in this sense, i.e. that only
want to access their arguments, and push some results, and otherwise
leave the Lua state alone.

"LuaJIT, here's a pointer of type 'int (*)( const char *, const char *
)', give it global name 'foo' and generate the glue-code that gets the
const char * out of the Lua state, and returns the returned int to its
correct place, and you can trust me that the function will not touch
the Lua state."

(Just like you can already use function_traits<> and some template
fiddling to let the C++ compiler generate the glue-code that
translates arguments and exceptions for such functions.)(Because, at
least in my applications, nearly all C++ functions that are callable
from Lua fall into this category, and it's quite convenient to neither
have every function explicitly use the Lua stack, nor having to
provide the type of the function, just "hey g++, here's a function,
figure out the type and create the appropriate CFunction".)

Regards, Colin