Re: LuaJIT2 performance for number crunching

[Francesco Abbate <francesco.bbt@...>]

2011/2/13 Leo Razoumov <slonik.az@gmail.com>:
> If performance is your main concern then C/C++/Fortran and sometimes
> Assembler are your only real choices especially is you a coding
> against a fixed deadline. With LuaJIT2 or any other smart dynamic
> optimizers fir that matter there are too many things beyond your
> immediate control. I personally, would like to use LuaJIT2 for
> numerics in a way I use MATLAB/Octave -- as a rapid fire mathematics
> at my finger tips. Great runtime performance is a big bonus but I
> would not bet my house on it.

Hi,

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.

I've recently integrated LuaJIT2-beta6 in GSL shell (see luajit2
branch in GIT repository) and I was exploring the possibility of a
native Lua implementation of ODE integration algorithms like
Runge-Kutta or other higher order algorithm.

The idea is that we should avoid the Lua/C interface because it does
kill the perfomance and Lua/C/Lua is even worst. It is otherwise known
that in some case the perfomance on LuaJIT2 can be on the par with
C/Fortran optimized code for pure procedural numeric intensive
algorithm, see the SciMark2 benchmark and the spectral-norm test at
the computer benchmark game.

It turns out that I've made un attempt with the RK4 algorithm
translated straightforwardly from C to Lua. It was a partial failure
because LuaJIT2 failed to optimize correctly the main loop but Mike
shown me a way to make LuaJIT2 optimizer works. The only problem that
I need to generate the lua code dynamically to specialize the code for
the dimension of the ODE system. This is in same way similar to C++
template programming where you parametrize with an integer to obtain
more specialized code.

Since LuaJIT2 is already integrated in GSL Shell (this is a great
thing for me) and it works like a charm I'm going to try to
implemented a full featured ODE integrator based on RK4 with dynamic
code generation as suggested by Mike. The idea is that the performance
could be *really* on the par or better to what I obtain with C code
using the GSL library. If the RK4 experiment works than I can
implement later more advanced algorithms like is done in the GSL
library.

By the way if someone want to help with this task he is very welcome.
My plan is the following:
- take the rk4_2d.lua code (modified by Mike)
- optimize it further to take advantage of Lua possiblities to return
  multiple values for returning the derivates
- fine tune this code
- use the basic stepper to implement an adaptive stepper with a nice
  Lua interface
- when the code works for a system N=2 take the code and transform it in a
  template to generate dynamically the code for any N between 1 and lets say
  10. For N > 10 we should probably avoid to expand the local variable and
  store each component in a FFI double VLA

So, now you know all my secret plan to dominate the world (of ODE
integration) ... :-)

-- 
Francesco