Re: LuaJIT Lua Gulf? (Was: Why I leave Lua..)

[Coda Highland <chighland@...>]

On Thu, Jul 10, 2014 at 10:44 PM, Eric Wing <ewmailing@gmail.com> wrote:
> On 7/10/14, Coda Highland <chighland@gmail.com> wrote:
>> On Thu, Jul 10, 2014 at 1:39 PM, Eric Wing <ewmailing@gmail.com> wrote:
>>>> Although even when not jitting, the hand-coded interpreter is going to
>>>> give that extra factor of 2 or 3 times - *if* the platform is
>>>> supported by LuaJIT.
>>>
>
>>
>> You can't make the comparison quite that easily. Optimized LuaJIT code
>> doesn't always look like optimized Lua code. And optimized LuaJIT code
>> when the JIT is unavailable looks different from optimized
>> LuaJIT-with-JIT code. The fact that LuaJIT's performance is comparable
>> even in a scenario that puts it at a disadvantage is pretty nice.
>
> The original claim was LuaJIT with its hand-crafted interpreter with
> JIT *disabled* would be 2x-3x faster. I'm contesting that and I think
> my comparison is apt.
>
> I have never seen a claim that LuaJIT would noticeably slower than
> regular Lua under these circumstances and I don't see why that would
> be. LuaJIT with its hand crafted assembly and non-self-imposed
> restrictions to stick to ANSI C should give it every advantage over
> stock Lua.

I meant at a disadvantage to its own potential performance (i.e.
running LuaJIT-optimized code), not relative to PUC Lua.

Specifically, using FFI structs outperforms using tables when you can
live with the restrictions (statically-typed fields, fixed list of
fields, can't be passed to a Lua C API function) nets a performance
gain in LuaJIT -- IIRC even with the JIT disabled.

>> Calls to the Lua C API interfere with the JIT. If you were to rewrite
>> the code to use the FFI, you'd likely be pushing higher numbers.
>
> I've seen other claims that suggest that static/compiled bindings are
> on par with what FFI does. And this is exactly what I've seen. And
> this kind of makes sense that the compiler would ultimately generate
> code that is accomplished what FFI does. And I know when I use libffi
> directly myself, there is runtime overhead in marshaling the
> arguments.

With the JIT disabled, yes, compiled bindings using the C API have the
potential to be faster than an FFI call.

I was referring to your comment that your app was running at 75% the
performance of C on desktop. With JIT enabled, FFI calls are
substantially faster (IIRC by an order of magnitude) than C API calls
-- the marshalling for the FFI call gets compiled, but the need arises
to marshal parameters to the C API function. Idiomatic LuaJIT code,
with the JIT enabled, making FFI calls should be able to do 95%+ the
performance of C. (It's actually possible in some rare cases for
idiomatic LuaJIT code to *beat* the performance of non-hand-tuned C
code thanks to the JIT compiler being able to do a better job of
profile-directed optimization.)

> Anyway, my point is that I've seen a lot of claims but very little to
> back them up. Furthermore, my results dispute some of these claims.
> (To be clear, I'm not disputing LuaJIT is fast with JIT enabled.)

I don't dispute your findings, for the code you're running. The claims
aren't referring to getting a free bonus to unmodified code. What I'm
pointing out is that you could rewrite some of your algorithms to take
advantage of what LuaJIT offers.

/s/ Adam