Re: Performance degraded significantly when enabling JIT
- From: Hoping White <baihaoping@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 26 Sep 2014 15:20:13 +0800
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?
在 2014年9月26日，下午3:04，Hoping White <baihaoping@xxxxxxxxx> 写道：
> 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’
>
>
> 在 2014年9月26日，下午12:32，soumith <soumith@xxxxxxxxx> 写道：
>
>> 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)
>>
>> On Thu, Sep 25, 2014 at 9:17 PM, Hoping White <baihaoping@xxxxxxxxx> wrote:
>> 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
>>
>> 在 2014年9月26日，上午11:57，soumith <soumith@xxxxxxxxx> 写道：
>>
>>> 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:
