lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 5/9/15, Brigham Toskin <> wrote:
> On Sat, May 9, 2015 at 4:47 PM, Eric Wing <> wrote:
>> On 5/9/15, Rena <> wrote:
>> > On Sat, May 9, 2015 at 1:01 PM, Roberto Ierusalimschy
>> > <> wrote:
>> >>> Using the C API will make LuaJIT's performance bottom out. If you're
>> >>> worried about performance across VMs, stick to pure Lua.
>> >>
>> >> That is not a valid advice across VMs. C code is much faster than
>> >> (non-JIT) Lua code. So, not using the C API will hurt Lua performance.
>> >>
>> >> -- Roberto
>> >>
>> >
>> > But Lua also has some overhead with calling into C, doesn't it? So
>> > some common operations are faster in pure Lua than in C? I'm sure I've
>> > heard that.
>> >
>> I did some microbenchmarks like 2 years ago on this which I think I
>> mentioned on the list. If I recall my experiments correctly, I was
>> surprised that this was not the case and the calling overhead of
>> calling C implemented functions from Lua was faster than calling Lua
>> functions.
> That's interesting to hear. Like everything, the details of the code
> involved probably make a difference. I'm also wondering, (a) whether this
> was PUC-Rio Lua or LuaJIT (or both)?, and (b) were you just measuring call
> overhead, or taking into account implementing equivalent calculations?
> --
> Brigham Toskin

It was just PUC-Rio. I think it was Lua 5.2.

I was only measuring call overhead. (A good search might reveal the
thread. I was doing this because I wanted a baseline to compare for
JavaScriptCore and v8.)

The functions in the test did almost nothing except be called. There
were a couple of permutations to return void or numbers and pass no
arguments up to a couple of numbers (and maybe a string test) to see
how arguments would affect things.

Beginning iPhone Games Development