Re: numerical Lua?

[Luis Carvalho <carvalho@...>]

> I am pleased at how complete your port is.  You've overloaded arithmetic
> operators and have even included support for N-d arrays. It is almost as
> easy to use as Matlab!  However there is still a performance issue which
> surprised me.  On my windows xp box  (amd x2 3800) I ran a simple benchmark
> that inverts some matrices and performs some other calculations.  I then ran
> the equivalent code in Matlab 6.5.
> 
> The results are
> NumLua 24 sec.s
> Matlab. 15.2 sec.s
> 
> here's the code for each
> 
> LUA
> 
> u0 = os.time()
> x = matrix(100,100)
> I = matrix.eye(100)
> for i,j in x:entries() do
> 		x[i][j] = math.random()
> end
> for q=1,1000 do
> 	x = I + matrix.inv(x)
> end
> u1 = os.time()
> print(u1-u0)
> 
> Matlab
> tic ;
> x = rand(100,100) ;
> I = eye(100) ;
> for q=1:1000
>     x = I + inv(x) ;
> end
> toc

Just a quick comment: you can gain some speed by using locals

local u0 = os.clock()
local x = matrix(100, 100)
local I = matrix.eye(100)
for i=1,matrix.size(x,1) do
	local r = x[i] -- i-th row
	for j=1,matrix.size(r) do
		r[j] = math.random()
	end
end
for q=1,1000 do x=I+matrix.inv(x) end
print(os.clock()-u0)

or even some functional flavor

local u0 = os.clock()
local x = matrix(100, 100):map(function(v) return math.random() end)
local I = matrix.eye(100)
for q=1,1000 do	x = I+matrix.inv(x) end
print(os.clock()-u0)

That won't save you much time, of course, since the bulk of the computation is
in the inv loop.

> Now since I used your binary distribution I'm not using tuned BLAS
> libraries, but then again neither is Matlab.  (I think 6.5 uses Atlas but
> I'm not sure).  Your code does a lot of type checking, but then again so
> does Matlabs.  I would have expected Matlab to incur more overhead and
> therefore the LUA code to be more competitive.  

Matlab uses Intel's MKL on Intel chips and ATLAS on AMDs. Moreover, Matlab
uses JIT to accelerate loops. However, I'm very positive that you can still beat
them by simply using optimized BLAS and LAPACK versions. I haven't tried
anything on Windows yet, but I think we can even use Matlab's libs! I made a
few benchmarks on a Xeon a few months ago and the results were encouraging:
around a 7 fold difference (!) for matrix entrywise operations -- that is,
something like x[i][j] = x[i-1][j+1] + 2. Matrix operations (sum, transpose,
multiplication) gave me similar results for both platforms because the
performance here is mainly due to blas/lapack libraries. I'll try to reproduce
the test and post the code later.

> One of the big attractions for using LUA for numerical applications is it's
> easy interface to C, (with the help of maybe tolua or SWIG).  With C doing
> the heavy number crunching, one can get a factor of 5 or 6 improvment in
> speed over Matlab.  (Contrary to the claims of some speed is still of huge
> importance for numerical applications.  I have Matlab scripts that take 2
> days to run, even on my overclocked dual core athlon)

Other attractions for numerics: lexical closures, coroutines, and proper tail
recursions. Not to mention speed and powerful semantics (Matlab cells are a
big "hack" compared to Lua tables).

> LUA is great for configuration and high level logic.  I have used it this
> way before with great success.  The problem now with the NumLua approach, 
> with all the syntactic sugar, is that an overhead penalty is being paid that
> defeats the purpose of using LUA.  If we want free numerical software, 
> SciPy is a lot more mature and also has a nice C interface.  

Numlua is very, very green. I have a lot plans for it -- sparse matrices,
quadratures, FFTs, plots, more statistics -- but no time for now. OTOH, there
are quite a few features in Numlua already, and I'll definitely dedicate some
love to them this summer and build a more stable and user friendly package.

Cheers,
luis.


-- 
A mathematician is a device for turning coffee into theorems.
        -- P. Erdos 

-- 
Luis Carvalho
Applied Math PhD Student - Brown University
PGP Key: E820854A <carvalho@dam.brown.edu>