Re: Is it supposed to be faster to call a C function than a Lua function when in Lua?

[William Ahern <william@...>]

On Thu, Jun 27, 2013 at 01:00:04PM -0700, Eric Wing wrote:
> > If you look at the c code of the Lua interpreter, this is not really
> > surprising. There is not really a language bridge at that point. The Lua
> > interpreter is in C as well. All it does is a call of a C function pointer.
> >
> 
> So just as an additional data point, I've been looking at
> JavaScriptCore and v8 which are also implemented in C/C++.
> (JavaScriptCore's JIT is disabled since I am testing it on iOS, while
> I'm doing v8 on Android which cannot disable JIT).
>
> In both cases, calling to C from Javascript was more expensive than
> calling C from Lua. In JSCore, the Javascript empty function call was
> faster than calling the C empty function, but both were slower than
> Lua calling a Lua function.
> 
> In v8, the empty Javascript function call was much faster, about 10x
> faster than the C call and about 5x faster than Lua. But I think I'm
> more surprised that v8's JIT didn't completely optimize out the loop
> and empty function and make the time 0.
> 

It's not that Lua is implemented in C, it's that it's running in the normal
C ABI environment for the platform, and the engine doesn't try to play
fast-and-loose with the C specification.

JIT'd environments usually implement their own execution environment to make
life simpler, including such things as calling conventions and specialized
data types. When they have to call out to "native C" routines, they have to
effectively marshal and unmarshal data to match the calling conventions and
memory model of the platform. Interactions between "native C" and a JIT
environment can be complex; the JIT code isn't simply calling a C function,
it has to ensure the entire environment is prepared to service that C call.

Perhaps more important is Lua's "stack" concept, which is really quite
brilliant in terms of making it efficient and convenient for Lua code and C
code to interact. I think this aspect of the Lua VM gets short shrift. Most
people don't appreciate its elegance, not just as an API but in the
implementation of the VM itself, promoting efficient interaction between the
C API and the Lua code.