Re: Performance degraded significantly when enabling JIT
- From: soumith <soumith@xxxxxxxxx>
- To: luajit <luajit@xxxxxxxxxxxxx>
- Date: Thu, 25 Sep 2014 20:57:04 -0700
LuaJIT for android does have bad performance with jit on. There is a
workaround for this,
//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.
On Thu, Sep 25, 2014 at 8:19 PM, null <xiqingdubu@xxxxxx> wrote:
> 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";<alvion@xxxxxxxxx>;
> *发送时间:* 2014年9月25日(星期四) 上午8:26
> *收件人:* "luajit"<luajit@xxxxxxxxxxxxx>;
> *主题:* Re: Performance degraded significantly when enabling JIT
>
> On Sat, Sep 20, 2014 at 1:20 AM, Mike Pall <mike-1409@xxxxxxxxxx> wrote:
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> >
> > > 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
>
Other related posts:
