lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Wed, Mar 24, 2010 at 2:49 PM, Mike Pall <mikelu-1003@mike.de> wrote:
> Ilya Martynov wrote:
>> We are embedding LuaJIT 1.1.5 into our own HTTP server so that we can
>> use Lua as a scripting language to write application business logic.
>> Recently we tried updating LuaJIT to 2.0.0-beta3 in the server and
>> noticed that it was actually 20% slower with our typical Lua programs.
>> On the first glance the main difference from benchmarks being
>> published so far on the maillist is that we have many C function calls
>> in our Lua programs, some being called in inner loops. So I was
>> wondering, could it be possible that LuaJIT 2 is actually slower on C
>> function calls then LuaJIT 1?
>
> If you have mostly C function calls in inner loops, your code will
> run in the LuaJIT 2.0 interpreter only and not benefit of the JIT
> compiler at all. The LuaJIT 2.0 interpreter is often faster, but
> in this case somewhat slower than the LuaJIT 1.1 JIT compiler.
>
> Solution: reduce the number of costly Lua/C transitions. I.e. write
> more code in Lua and avoid calls to trivial C helper functions.
>
> [The planned FFI for LuaJIT 2.0 will speed up calls to C functions.
> But you'll need to rewrite your bindings (much easier though).]

I see, unfortunately reducing the number of Lua/C transitions is not
an option for us. Those C functions are not trivial helpers, but
rather complex data lookup algorithms which cannot really be written
in pure Lua for performance and memory usage reasons. I guess we'll be
waiting for FFI before switching to LuaJIT 2 then. In any case thank
you for your great work on LuaJIT.

-- 
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd