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

[Eric Wing <ewmailing@...>]

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.


> 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.

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.)

Thanks,
Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/