[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Improving performance of Lua on low-end systems
- From: Coda Highland <chighland@...>
- Date: Wed, 29 Oct 2014 11:05:20 -0700
On Tue, Oct 28, 2014 at 7:48 PM, William Ahern
<william@25thandclement.com> wrote:
> _However_, it turns out that LuaJIT apparently does optimize calls to its
> built-ins. If I replace os.time with a C function
>
> static int inc(lua_State *L) {
> lua_Number i = lua_tonumber(L, 1);
> lua_pushnumber(L, i + 1);
> return 1;
> } /* inc() */
>
> and replace the call-out in the script below with
>
> j = inc(j) --> inc is a local
>
> then I got
>
> Lua5.1: 2.932s
> Lua5.2: 2.885s
> LuaJIT: 2.232s
>
> which is only ~3/4 the execution time of Lua 5.1/5.2.
Heads up, by doing so you've thrown LuaJIT right into its worst-case
scenario. It is well-known among LuaJIT users that Lua C API calls are
substantially more expensive than in-Lua calls or FFI calls.
Code written idiomatically for performance in the two languages often
looks rather different. Since the cost of a C API call in LuaJIT is
proportionally so much higher, that's that much more encouragement to
avoid bouncing across that layer as much as possible. If you can
actually use the JIT instead of being stuck in interpreter mode (the
PSP ought to support this? but I don't know) then you'd be better off
converting your C code to Lua code using the FFI for native code
calls.
/s/ Adam