Re: LuaJIT2 - Performance Expectancies

["Matthew P. Del Buono" <delbu9c1@...>]

Mike Pall wrote:
> Matthew P. Del Buono wrote:
>> Unfortunately, this required a fully automated build across several
>> platforms using CMake, so I had to essentially rewrite LuaJIT's makefile
>> in CMake format and consider the (notably minor, but important)
>> differences between platforms. Because I've never used LuaJIT before,
>> I'm pretty willing to admit I'll have likely screwed something up there.
> 
> Wouldn't it be easier to build LuaJIT separately and then add it
> as a link dependency to the project?
> 

For me, it would be easier. For everyone else, well, let's just say
there's no reason for them to put the effort in right now, so fully
automating the process makes the buy-in process much easier.

> Oh, BTW, a common pitfall other people supposedly have fallen into
> before (ahemm): make sure your app doesn't sync to a fixed frame
> rate or some subdivisor of it. Because then you'll never be able
> to tell a difference in the FPS. ;-)
> 

Actually, we're actively investigating this possibility, because we're
seeing framerates in excess of 2000 on Linux, and 200 and under on
Windows (without exaggeration in the difference). We're convinced
there's something capping the rate somewhere, we just haven't been able
to find out where yet. But that's a topic for another time and place :)


> Profile your whole application and find out where it spends most
> of its CPU time. If it's not inside Lua, then there's no point in
> spending time on improving its performance.

This is actually an interesting point. I had actually profiled the
application before deciding to make this move and it was a driving
factor in making the switch: Lua functions were frequently on the top of
the hot spots list. I re-ran the profile and noticed a drop on the Lua
side, but LuaJIT still comes up on top on percentage CPU time:

lj_BC_TGETS = 13.81 (LuaJIT)
Main::mainLoop = 8.95 (Application)
lj_str_new = 7.17 (LuaJIT)
_RTC_CheckStackVars = 6.15 (VC Debug Check)
Grid::render = 5.00 (Application)

A rule of thumb I follow is that when you start hitting
_RTC_CheckStackVars (a debug analysis function added in by Visual
Studio), you are going too far in analyzing performance. To compare,
numbers I was getting before showed Lua having about 8 of the top 10
functions on CPU time. While LuaJIT still comes out on top, it is much
better blended in with the application, which bodes well for what we
plan to do with Lua in the near future (which will be a lot more Lua and
a lot less C++).

Thanks for reminding me to re-check the profile.

> 
>> Because it's not a standalone application, it seems I can't use
>> the "-jv" option.
> 
> I bet you can. Just redirect it to a file:
> 
>   require("jit.v").start("dump.txt")
> 

Very nice, thanks :)


======

Matthew P. Del Buono