Re: LuaJIT2 performance for number crunching

[Leo Razoumov <slonik.az@...>]

On Mon, Feb 14, 2011 at 03:08, Francesco Abbate <francesco.bbt@gmail.com> wrote:
> just to be more clear. I've implemented an ODE integrator in GSL Shell
> by using the GSL library but the perfomance is a disaster because of
> we need to provide a pointer to a C function that evaluate the
> derivates for the ODE system. The performance is very bad because we
> do a transition
>
> Lua -> C -> Lua
>
> and the C function call many times a single Lua function. These is
> actually a sort of worst case scenario that LuaJIT is not able to
> optimize.
>

Francesco,
As I  mentioned earlier, I would encourage you to try out an idea
proposed by Mike in another thread
http://lua-users.org/lists/lua-l/2011-02/msg00455.html

It works similar to Lua coroutines and allows you to run your LuaJIT2
in one coroutine and your GSL C-implemented rk4 in another coroutine
passing data between the two like you would do with resume/yield
mechanism (from within rk4 callback). By doing so you avoid going
through Lua's C-stack manipulations. LuaJIT will trace/optimize calls
to your Lua implemented function/derivative. You do not need to
reimplement rk4 in Lua at all. Looks like the best of both worlds if
you can wrap your head around non-conventional call chain. If married
to ffi this method might reduce Lua->C->Lua overhead to the bare
minimum.
I looked into available lightweight C-coroutine libraries and so far
libconcurrency looks promissing.
http://code.google.com/p/libconcurrency/

--Leo--