Re: LuaJIT2 performance for number crunching

[T T <t34www@...>]

On 14 February 2011 23:10, Francesco Abbate <francesco.bbt@gmail.com> wrote:
> 2011/2/14 Leo Razoumov <slonik.az@gmail.com>:
>> 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
>
> I see that you are intrigued by this idea :-) if you succeed to obtain
> something that works I would be interested but my feeling is that it
> is quite awkward to make it work and I confess that I don't master
> this kind of wizardry of multiple C stacks in a single process and
> switching back and forth... I don't know...

I have to say that I'm intrigued by this idea too.  It could be the
ultimate answer for performance sensitive Lua / C transitions,
especially if it could be wrapped in some convenient interface and
(ideally) become included in luajit.  Are there any limitations to
this technique or cloud it be used with pretty much all of Lua
(including binary modules)?

> For the other side I'm very excited about the RK4 ODE integrator. I
> rewrote the code as Mike suggested, see the file in attachment, and
> - the code was much more simple and expressive and beautiful than the
> original C code
> - with LuaJIT2-beta6 and FFI it was running 2.6x faster than C code!!!
>
> Here the timing:
> rk4-unroll.lua with LuaJIT2: 0m0.240s
> C code with -O2 with GSL library: 0m0.638s

Incidentally, I modified your original code (rk4.lua, line 10):

   darray = function(dim) local t = {}; for k = 1,dim do t[k] = 0;
end; return t end

and tried it with different values of dim.  The results (in sec):

  dim=2    time=5.45 sec
  dim=3    time=1.23 sec
  dim=4    time=1.25 sec
  dim=5    time=1.10 sec
  dim=6    time=1.16 sec
  dim=7    time=1.23 sec
  dim=8    time=1.30 sec
  dim=9    time=1.72 sec

So, in this case one gets the best speed up (~5x) by asking to do 2.5x
more work ;)

> The result is absolutely remarkable. It is something absolutely great,
> this will change the way people will do numeric calculations in the
> future.
>
> What I need to do now is to transform this code in a template to
> specialize it for systems of dimension N. For the moment I didn't have
> the time to look at the link of David I will probably look at this
> tomorrow (I hope I will have the time).

While the result is certainly impressive, a huge drawback of
templating is reduced code readability.  It's definitely not the type
of code I would like to write or work with.  One would hope that such
a (common?) case as unrolling small loops could be done automatically
for the programmer, rather than require writing special templating
solutions.

Cheers,

Tomek