[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Is it supposed to be faster to call a C function than a Lua function when in Lua?
- From: William Ahern <william@...>
- Date: Thu, 27 Jun 2013 14:44:27 -0700
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
> I'm doing v8 on Android which cannot disable JIT).
> faster than calling the C empty function, but both were slower than
> Lua calling a Lua function.
> 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.