Performance degraded significantly when enabling JIT

[joe]

I'm working on a game using a heavily modified version of the MOAI
game engine and LuaJIT 2.0.2. Almost all the non-MOAI parts of the
game are implemented in Lua, so Lua takes a significant amount of our
frame time (more than half). Switching to LuaJIT from traditional Lua
gave us a significant performance boost. However when JIT compilation
is enabled, we actually experience a significant performance decrease
compared to when it is disabled, roughly 15-20%. I've spent weeks now
trying to make the game more JIT friendly, with no measurable benefit.
Our lua code is largely pure Lua with few calls into C++, so seems to
be an ideal candidate for LuaJIT compilation but we are not seeing the
results.

I've tried analyzing the trace failures with the tools in v.lua, and
I've gotten rid of hundreds of the most common NYI issues we have in
our code, replacing inner loop C functions with ffi versions, getting
rid of pairs() iterations, getting rid of string concats, etc. I've
done all this with pretty much no measurable benefit. I can tell from
checking the output from v.lua that I am in fact fixing those
problems, but I am still not seeing any performance gains, and I'm
running out of things to try.

So if I may I'd like to ask a few questions:

Is it expected that enabling JIT will degrade performance for some
applications?
What might cause that, simply the overhead of attempting to compile
the traces with no performance benefit to offset it?
Is finding and fixing the most common NYI issues not the best way
address the issue?
Is there anything else I can do to diagnose the problem, or is it most
likely that our application will not benefit from JIT compilation, and
I should move on to higher level Lua optimizations?

Thanks,
Joe Virskus
Double Fine Productions

[Konstantin Olkhovskiy]

I would suggest to use the built-in profiler available in the v2.1 branch.

Also trying the v2.1 for your game is a good idea, it's faster than v2.0,
but not yet released.

[joe]

I appreciate the suggestion. I did upgrade to 2.1 as the first thing, but I
was never able to get it to be stable. Specifically, I was getting
completely random nil reference errors any time JIT was enabled (it was
stable with JIT disabled).

If there was something that suggested that this issue was specific to 2.0.2
I would put more effort into upgrading, but otherwise I'm not sure it's
worth the effort.

Joe

Post by Konstantin Olkhovskiy
I would suggest to use the built-in profiler available in the v2.1 branch.
Also trying the v2.1 for your game is a good idea, it's faster than v2.0,
but not yet released.

[Coda Highland]

Post by joe
I appreciate the suggestion. I did upgrade to 2.1 as the first thing, but I
was never able to get it to be stable. Specifically, I was getting
completely random nil reference errors any time JIT was enabled (it was
stable with JIT disabled).
If there was something that suggested that this issue was specific to 2.0.2
I would put more effort into upgrading, but otherwise I'm not sure it's
worth the effort.
Joe

Instability with JIT enabled often means you're not properly anchoring
your data and things are getting freed when you don't expect them to,
or that you're invoking a Lua C API function in a way that isn't
permitted.

Honestly I'm a little bit surprised that you're NOT having the same
instabilities in 2.0.2.

/s/ Adam

[Mike Pall]

Post by joe
Is it expected that enabling JIT will degrade performance for some
applications?

Only in pathological cases.

Post by joe
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.

Post by joe
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.

Post by joe
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.

Post by joe
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

[joe]

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.

I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.

The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.

Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.

Thanks,
joe v

[null]

I'm working on a game using Unity3D and LuaJIT 2.0.3.
‍Performance degraded significantly when running on android.‍
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)‍


here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28‍






------------------ 原始邮件 ------------------
发件人: "joe";<***@gmail.com>;
发送时闎: 2014幎9月25日(星期四) 䞊午8:26
收件人: "luajit"<***@freelists.org>;

䞻题: Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.

I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.

The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.

Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.

Thanks,
joe v

[Yichun Zhang (agentzh)]

Hello!

Post by joe
However when JIT compilation
is enabled, we actually experience a significant performance decrease
compared to when it is disabled, roughly 15-20%.

Will you try the on-CPU flame graph tools to generate a graph for your
loaded game hot on CPU? See

https://github.com/openresty/nginx-systemtap-toolkit#sample-bt

Perferrably, you can generate another graph for the same game with JIT
disabled so that we can compare.

By looking at the flame graphs, we can immediately know if it is
LuaJIT VM entry/exit being hot, or anything else.

Regards,
-agentzh

[null]

I'm working on a game using Unity3D and LuaJIT 2.0.3.
‍Performance degraded significantly when running on android.‍
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)‍


here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28‍






bulding libluajit.so for android using config as follow


1 LJ=./build/android #猖译后攟眮目圕
2 LJ_INC=$LJ/include #攟眮倎文件的目圕
3 LJ_LIBS=$LJ/libs #攟眮铟接库文件的目圕
4 NDK=/Users/ben/download/android-ndk-r8e
5
6 # Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo)
7 NDKABI=8
8 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
9 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
10 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
11 make clean
12 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" TARGET_SYS=Linux
13
14 rm -rf $LJ/
15 mkdir -p $LJ_INC/
16 cp src/lua*.h* $LJ_INC/
17 cp src/lauxlib.h $LJ_INC/
18
19 TDIR=$LJ_LIBS/armeabi
20 mkdir -p $TDIR/
21 cp src/libluajit.* $TDIR/
22
23 # Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS)
24 NDKABI=14
25 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
26 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
27 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
28 NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8"
29 make clean
30 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" TARGET_SYS=Linux
. 31
32 TDIR=$LJ_LIBS/armeabi-v7a
33 mkdir -p $TDIR/
34 cp src/libluajit.* $TDIR/‍

------------------ 原始邮件 ------------------
发件人: "joe";<***@gmail.com>;
发送时闎: 2014幎9月25日(星期四) 䞊午8:26
收件人: "luajit"<***@freelists.org>;

䞻题: Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.

I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.

The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.

Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.

Thanks,
joe v

[soumith]

LuaJIT for android does have bad performance with jit on. There is a
workaround for this,
http://www.freelists.org/post/luajit/Android-performance-drop-moving-from-LuaJIT201-LuaJIT202,8

You just have to add this to the top of your lua entrypoint script:

require("jit.opt").start("sizemcode=524288,maxmcode=524288")
for i=1,100 do end -- Force allocation of the first segment.

Post by null
I'm working on a game using Unity3D and LuaJIT 2.0.3.
Performance degraded significantly when running on android.
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)
here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28
bulding libluajit.so for android using config as follow
1 LJ=./build/android #±àÒëºó·ÅÖÃÄ¿ÂŒ
2 LJ_INC=$LJ/include #·ÅÖÃÍ·ÎÄŒþµÄÄ¿ÂŒ
3 LJ_LIBS=$LJ/libs #·ÅÖÃÁŽœÓ¿âÎÄŒþµÄÄ¿ÂŒ
4 NDK=/Users/ben/download/android-ndk-r8e
5
6 # Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo)
7 NDKABI=8
8 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
9 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
10 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
11 make clean
12 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF"
TARGET_SYS=Linux
13
14 rm -rf $LJ/
15 mkdir -p $LJ_INC/
16 cp src/lua*.h* $LJ_INC/
17 cp src/lauxlib.h $LJ_INC/
18
19 TDIR=$LJ_LIBS/armeabi
20 mkdir -p $TDIR/
21 cp src/libluajit.* $TDIR/
22
23 # Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS)
24 NDKABI=14
25 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
26 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
27 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
28 NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8"
29 make clean
30 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" TARGET_SYS=Linux
. 31
32 TDIR=$LJ_LIBS/armeabi-v7a
33 mkdir -p $TDIR/
34 cp src/libluajit.* $TDIR/
------------------ Ô­ÊŒÓÊŒþ ------------------
*·¢ËÍʱŒä:* 2014Äê9ÔÂ25ÈÕ(ÐÇÆÚËÄ) ÉÏÎç8:26
*Ö÷Ìâ:* Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.
I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.
The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.
Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.
Thanks,
joe v

[Hoping White]

Hi Soumith

Can you give more detail one "Top of lua entry point script¡±?
Because I have tried in cocos2dx and it does no good.

I wonders if I haven¡¯t done things properly, and the only point is lua entry point script.

In cocos2dx, lua process as follows:
1¡¢new lua_State
2¡¢set lua_loader
3¡¢register some cpp interfaces with tolua
4¡¢execute entry lua script

I have tried to add the code in step4, and it seems no effect.
Do I have to put the code after step 1 or something else?

Thanks very much

LuaJIT for android does have bad performance with jit on. There is a workaround for this,
http://www.freelists.org/post/luajit/Android-performance-drop-moving-from-LuaJIT201-LuaJIT202,8
require("jit.opt").start("sizemcode=524288,maxmcode=524288")
for i=1,100 do end -- Force allocation of the first segment.
I'm working on a game using Unity3D and LuaJIT 2.0.3.
Performance degraded significantly when running on android.
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)
here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28
bulding libluajit.so for android using config as follow
1 LJ=./build/android #±àÒëºó·ÅÖÃÄ¿ÂŒ
2 LJ_INC=$LJ/include #·ÅÖÃÍ·ÎÄŒþµÄÄ¿ÂŒ
3 LJ_LIBS=$LJ/libs #·ÅÖÃÁŽœÓ¿âÎÄŒþµÄÄ¿ÂŒ
4 NDK=/Users/ben/download/android-ndk-r8e
5
6 # Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo)
7 NDKABI=8
8 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
9 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
10 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
11 make clean
12 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" TARGET_SYS=Linux
13
14 rm -rf $LJ/
15 mkdir -p $LJ_INC/
16 cp src/lua*.h* $LJ_INC/
17 cp src/lauxlib.h $LJ_INC/
18
19 TDIR=$LJ_LIBS/armeabi
20 mkdir -p $TDIR/
21 cp src/libluajit.* $TDIR/
22
23 # Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS)
24 NDKABI=14
25 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
26 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
27 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
28 NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8"
29 make clean
30 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" TARGET_SYS=Linux
. 31
32 TDIR=$LJ_LIBS/armeabi-v7a
33 mkdir -p $TDIR/
34 cp src/libluajit.* $TDIR/
------------------ Ô­ÊŒÓÊŒþ ------------------
·¢ËÍʱŒä: 2014Äê9ÔÂ25ÈÕ(ÐÇÆÚËÄ) ÉÏÎç8:26
Ö÷Ìâ: Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.
I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.
The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.
Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.
Thanks,
joe v

[soumith]

Hmmm,

How about if you execute a buffer after step(1)?

I was using Lua directly (i.e. no cocos2d or other engines), and as soon as
I created a lua-state, I executed this two-line code in that state (with
luaL_loadbuffer + lua_pcall)

Post by Hoping White
Hi Soumith
Can you give more detail one "Top of lua entry point script¡±?
Because I have tried in cocos2dx and it does no good.
I wonders if I haven¡¯t done things properly, and the only point is lua
entry point script.
1¡¢new lua_State
2¡¢set lua_loader
3¡¢register some cpp interfaces with tolua
4¡¢execute entry lua script
I have tried to add the code in step4, and it seems no effect.
Do I have to put the code after step 1 or something else?
Thanks very much
LuaJIT for android does have bad performance with jit on. There is a workaround for this,
http://www.freelists.org/post/luajit/Android-performance-drop-moving-from-LuaJIT201-LuaJIT202,8
require("jit.opt").start("sizemcode=524288,maxmcode=524288")
for i=1,100 do end -- Force allocation of the first segment.

Post by null
I'm working on a game using Unity3D and LuaJIT 2.0.3.
Performance degraded significantly when running on android.
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)
here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28
bulding libluajit.so for android using config as follow
1 LJ=./build/android #±àÒëºó·ÅÖÃÄ¿ÂŒ
2 LJ_INC=$LJ/include #·ÅÖÃÍ·ÎÄŒþµÄÄ¿ÂŒ
3 LJ_LIBS=$LJ/libs #·ÅÖÃÁŽœÓ¿âÎÄŒþµÄÄ¿ÂŒ
4 NDK=/Users/ben/download/android-ndk-r8e
5
6 # Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo)
7 NDKABI=8
8 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
9 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
10 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
11 make clean
12 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" TARGET_SYS=Linux
13
14 rm -rf $LJ/
15 mkdir -p $LJ_INC/
16 cp src/lua*.h* $LJ_INC/
17 cp src/lauxlib.h $LJ_INC/
18
19 TDIR=$LJ_LIBS/armeabi
20 mkdir -p $TDIR/
21 cp src/libluajit.* $TDIR/
22
23 # Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS)
24 NDKABI=14
25 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
26 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
27 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
28 NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8"
29 make clean
30 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" TARGET_SYS=Linux
. 31
32 TDIR=$LJ_LIBS/armeabi-v7a
33 mkdir -p $TDIR/
34 cp src/libluajit.* $TDIR/
------------------ Ô­ÊŒÓÊŒþ ------------------
*·¢ËÍʱŒä:* 2014Äê9ÔÂ25ÈÕ(ÐÇÆÚËÄ) ÉÏÎç8:26
*Ö÷Ìâ:* Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.
I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.
The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.
Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.
Thanks,
joe v

[Hoping White]

Hi

I have tried this code and got the following error just after openlibs:

Cocos2d: [LUA ERROR] [string "require('jit.opt').start('sizemcode=524288,ma..."]:1: unknown or malformed optimization flag 'sizemcode=524288,maxmcode=524288¡¯

Post by soumith
Hmmm,
How about if you execute a buffer after step(1)?
I was using Lua directly (i.e. no cocos2d or other engines), and as soon as I created a lua-state, I executed this two-line code in that state (with luaL_loadbuffer + lua_pcall)
Hi Soumith
Can you give more detail one "Top of lua entry point script¡±?
Because I have tried in cocos2dx and it does no good.
I wonders if I haven¡¯t done things properly, and the only point is lua entry point script.
1¡¢new lua_State
2¡¢set lua_loader
3¡¢register some cpp interfaces with tolua
4¡¢execute entry lua script
I have tried to add the code in step4, and it seems no effect.
Do I have to put the code after step 1 or something else?
Thanks very much

LuaJIT for android does have bad performance with jit on. There is a workaround for this,
http://www.freelists.org/post/luajit/Android-performance-drop-moving-from-LuaJIT201-LuaJIT202,8
require("jit.opt").start("sizemcode=524288,maxmcode=524288")
for i=1,100 do end -- Force allocation of the first segment.
I'm working on a game using Unity3D and LuaJIT 2.0.3.
Performance degraded significantly when running on android.
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)
here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28
bulding libluajit.so for android using config as follow
1 LJ=./build/android #±àÒëºó·ÅÖÃÄ¿ÂŒ
2 LJ_INC=$LJ/include #·ÅÖÃÍ·ÎÄŒþµÄÄ¿ÂŒ
3 LJ_LIBS=$LJ/libs #·ÅÖÃÁŽœÓ¿âÎÄŒþµÄÄ¿ÂŒ
4 NDK=/Users/ben/download/android-ndk-r8e
5
6 # Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo)
7 NDKABI=8
8 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
9 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
10 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
11 make clean
12 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" TARGET_SYS=Linux
13
14 rm -rf $LJ/
15 mkdir -p $LJ_INC/
16 cp src/lua*.h* $LJ_INC/
17 cp src/lauxlib.h $LJ_INC/
18
19 TDIR=$LJ_LIBS/armeabi
20 mkdir -p $TDIR/
21 cp src/libluajit.* $TDIR/
22
23 # Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS)
24 NDKABI=14
25 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
26 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
27 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
28 NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8"
29 make clean
30 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" TARGET_SYS=Linux
. 31
32 TDIR=$LJ_LIBS/armeabi-v7a
33 mkdir -p $TDIR/
34 cp src/libluajit.* $TDIR/
------------------ Ô­ÊŒÓÊŒþ ------------------
·¢ËÍʱŒä: 2014Äê9ÔÂ25ÈÕ(ÐÇÆÚËÄ) ÉÏÎç8:26
Ö÷Ìâ: Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.
I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.
The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.
Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.
Thanks,
joe v

[Hoping White]

I think I found the problem, refer to luajit document the following code is correct

"require('jit.opt').start('sizemcode=524288','maxmcode=524288')\nfor i=1,100 do end¡±

according to document

sizemcode Size of each machine code area in KBytes (Windows: 64K)
maxmcode Max. total size of all machine code areas in Kbytes

so 512 or 524288 is 512k?

Post by Hoping White
Hi
Cocos2d: [LUA ERROR] [string "require('jit.opt').start('sizemcode=524288,ma..."]:1: unknown or malformed optimization flag 'sizemcode=524288,maxmcode=524288¡¯

Post by soumith
Hmmm,
How about if you execute a buffer after step(1)?
I was using Lua directly (i.e. no cocos2d or other engines), and as soon as I created a lua-state, I executed this two-line code in that state (with luaL_loadbuffer + lua_pcall)
Hi Soumith
Can you give more detail one "Top of lua entry point script¡±?
Because I have tried in cocos2dx and it does no good.
I wonders if I haven¡¯t done things properly, and the only point is lua entry point script.
1¡¢new lua_State
2¡¢set lua_loader
3¡¢register some cpp interfaces with tolua
4¡¢execute entry lua script
I have tried to add the code in step4, and it seems no effect.
Do I have to put the code after step 1 or something else?
Thanks very much

LuaJIT for android does have bad performance with jit on. There is a workaround for this,
http://www.freelists.org/post/luajit/Android-performance-drop-moving-from-LuaJIT201-LuaJIT202,8
require("jit.opt").start("sizemcode=524288,maxmcode=524288")
for i=1,100 do end -- Force allocation of the first segment.
I'm working on a game using Unity3D and LuaJIT 2.0.3.
Performance degraded significantly when running on android.
here is the test code.
1 g_logger:debug("jit version", jit.version)
2 jit.off()
3 -- loop test
4 local f = function (n)
5 return n + 1
6 end
. 7 local count = 1000000
8
9 local sec = os.time()
10
11 local n = 0
12 for i = 1, count do n = f(n) end
13 g_logger:debug("jit.off loop test cost = ", os.time() - sec)
14
15 jit.on()
16 local sec = os.time()
17 local n = 0
18 for i = 1, count do n = f(n) end
19 g_logger:debug("jit.on loop test cost = ", os.time() - sec)
20
21
^ 22 jit.off()
23 -- create table test
24 local f = function ()
25 return {}
26 end
' 27
28 local sec = os.time()
29
30 for i = 1, count do f() end
31 g_logger:debug("jit.off create table test cost = ", os.time() - sec)
32
33 jit.on()
34 local sec = os.time()
35 local n = 0
36 for i = 1, count do f() end
37 g_logger:debug("jit.on create table test cost = ", os.time() - sec)
here is the result
DEBUG "jit version", "LuaJIT 2.0.3"
DEBUG "jit.off loop test cost = ", 0
DEBUG "jit.on loop test cost = ", 27
DEBUG "jit.off create table test cost = ", 0
DEBUG "jit.on create table test cost = ", 28
bulding libluajit.so for android using config as follow
1 LJ=./build/android #±àÒëºó·ÅÖÃÄ¿ÂŒ
2 LJ_INC=$LJ/include #·ÅÖÃÍ·ÎÄŒþµÄÄ¿ÂŒ
3 LJ_LIBS=$LJ/libs #·ÅÖÃÁŽœÓ¿âÎÄŒþµÄÄ¿ÂŒ
4 NDK=/Users/ben/download/android-ndk-r8e
5
6 # Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo)
7 NDKABI=8
8 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
9 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
10 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
11 make clean
12 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" TARGET_SYS=Linux
13
14 rm -rf $LJ/
15 mkdir -p $LJ_INC/
16 cp src/lua*.h* $LJ_INC/
17 cp src/lauxlib.h $LJ_INC/
18
19 TDIR=$LJ_LIBS/armeabi
20 mkdir -p $TDIR/
21 cp src/libluajit.* $TDIR/
22
23 # Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS)
24 NDKABI=14
25 NDKVER=$NDK/toolchains/arm-linux-androideabi-4.6
26 NDKP=$NDKVER/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-
27 NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
28 NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8"
29 make clean
30 make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" TARGET_SYS=Linux
. 31
32 TDIR=$LJ_LIBS/armeabi-v7a
33 mkdir -p $TDIR/
34 cp src/libluajit.* $TDIR/
------------------ Ô­ÊŒÓÊŒþ ------------------
·¢ËÍʱŒä: 2014Äê9ÔÂ25ÈÕ(ÐÇÆÚËÄ) ÉÏÎç8:26
Ö÷Ìâ: Re: Performance degraded significantly when enabling JIT

Post by Mike Pall
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.

We use very little of the classic Lua/C API, and as I mentioned we
have converted most of our inner-loop C functions to FFI, so I don't
expect this to be the issue.

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

Well, this is certainly possible. A large portion of our frame time
is spent in our character decision making, which uses a utility
framework that is basically evaluating dozens of different utility
functions for hundreds or thousands of potential actions.
Unfortunately I think it's too late in the process to be thinking
about rewriting it to be more data driven.

Post by Mike Pall
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.

We're defining both LUA_USE_ASSERT and LUA_USE_APICHECK in our debug
build and not seeing any asserts get tripped, so I think this is not
the issue.

Post by Mike Pall
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.

As I understand it, those tools only exist in 2.1 which I haven't been
able to make stable in our codebase. I get seemingly random nil
reference errors, including tables that are basically "static" (class
tables for example). This only happens when using 2.1 with JIT
enabled, neither 2.1 interpreted nor 2.0.2 with JIT enabled exhibit
the issue.
I have been able to get a basic third party hook based profiler
working to identify our problem areas, but of course it doesn't work
very well with JIT enabled, and certainly doesn't give me any JIT
compilation specific data.
The only profiling data I can gather effectively is with our own
in-game profiling tools which only profile functions we specify and
are useful for figuring out which areas are causing trouble, but offer
no insight into what may be preventing JIT compilation from yielding
any benefits.

Post by Mike Pall

Post by joe
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.

Well, it's a LOT more than just glue logic. We're using LUA for all
our character behaviors, pathfinding, and game logic. We get
consistently worse performance with JIT enabled across all of our test
cases, each of which stress a different part of our code base. This
suggests to me that the problem is something global, but I have no
idea what.
Anyway, thanks for the help. We may just have to ship without JIT
enabled. We still get a huge performance boost from LuaJIT as
compared to plain old Lua.
Thanks,
joe v