lua-users home
lua-l archive

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

On 7/11/2014 7:44 AM, Eric Wing 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.
fyi: In luajittex we observe a speedup of 20-40% when 50% of the time is spent in Lua. This is because the LuaJIT vm is about twice as fast. I never enable jit itself as it slows down a run (tex runs are one-shots and don't benefit much from compiled code that runs for ages); we did lots of tests in that area.
Sometimes we cannot use LuaJIT because it has limitations (like the limited number of constants in some places). We also used a patched string hash methods (the original Lua 5.1 one) because there are cases where luaJIT can come to a grinding halt (we also tend to set the Lua hash max to 64 as its nicer for utf strings). Sometimes speed can come at a price and for us it means that we consider luatex (with lua) as the reference, and luajittex (with LuaJIT) as a companion that can be used in predictable situations. In any case, Lua is extremely fast and keeps surprising me and maybe some day the stock Lua vm will become even faster.
So, if one uses LuaJIT and compares to Lua it makes sense to test with and without jit enabled (just compare the two vm's). Often tests are done with numbers but when lots of strings are involved, as in our case the picture might look different. 


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


It's definitely fast with jit disabled -)

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
    tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------