Re: Performance degraded significantly when enabling JIT

  • From: Mike Pall <mike-1409@xxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sat, 20 Sep 2014 13:20:12 +0200

joe wrote:
> Is it expected that enabling JIT will degrade performance for some
> applications?

Only in pathological cases.

> What might cause that, simply the overhead of attempting to compile
> the traces with no performance benefit to offset it?

The compiler has pretty extensive measures to limit unprofitable
compilation attempts. The overhead of the JIT compiler itself is
rarely, if ever, a problem.

There are two main circumstances where JIT-compiled code may be
less efficient than interpreted code: 1. lots of trace entries and
exits with very short traces inbetween or 2. very branchy code
with many unbiased branches.

The main cause for 1. are calls to C/C++ code via the classic
Lua/C API or lots of calls into the VM from the C/C++ side.

The main cause for 2. is complex decision code that's better
rewritten using a data-driven approach, e.g. state machines.

Or it could be something seemingly unrelated, e.g. a misuse of the
Lua/C API (esp. wrt. stack levels) that spills over into the VM
and leads to excessive recompilations. Enable API check assertions
(in Lua and LuaJIT) during development, disable them when profiling.

> Is finding and fixing the most common NYI issues not the best way
> address the issue?

You should profile first. Many NYI's have zero impact on actual
performance, since they are outside of the hot code paths.

> Is there anything else I can do to diagnose the problem,

Profile, profile, profile. Check which code is running only
interpreted and/or code that's compiled, but takes up more time
than interpreted. E.g. -jp=vf to find the interpreted functions or
-jp=fv or -jp=lv to dig deeper.

> or is it most
> likely that our application will not benefit from JIT compilation, and
> I should move on to higher level Lua optimizations?

Can't say without more details. But it ought to benefit, if it's
more than just glue logic.

--Mike

Other related posts: