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

[Coda Highland <chighland@...>]

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.
>
> So I would like to see real numbers on this and document under which
> circumstances and try to avoid propaganda because bad information can
> encourage bad decisions. I recently did some internal benchmarks of
> LuaJIT vs. Lua 5.3 work 2 on an iPad mini (1st gen). The iPad
> disallows JIT so LuaJIT must go through the interpreted mode. I saw no
> speed difference between the two. (I have heard the claims the
> hand-coded interpreter still yielded significant benefits, and I'm
> disappointed they didn't live up.)

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.

> Repeating the same benchmark on a desktop where LuaJIT can use JIT, I
> did see the significant speedup of course.
>
> The experiment was a sprite test with SDL bound to Lua (using
> traditional compiled techniques, not FFI). So the two common hot paths
> were calling into C (to call SDL drawing APIs) and to actually
> compute/move the sprites around. I also wrote a pure C version as a
> control. Off the top of my head, I think Lua 5.3 was a little shy of
> 60% of C. LuaJIT with JIT enabled was 75% of C. (I consider this
> pretty good because I expected less since most of the code crosses
> into C...I was surprised how much LuaJIT could speed up my simple
> sprite movement code.)

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.

/s/ Adam