> It seems that runtime of lapack's dgemm function
> depends on the densities of its arguments
> (as contrasted to maxima's ".").
> So dgemm outperforms "." only when the matrices
> are very sparse.
> Below you see the results of squaring 400 by 400
> and 900 by 900 binary matrices with different
> numbers of 1's.
> I use Maxima 5.22.1 in Windows XP.
>
IIRC, Maxima on Windows uses gcl. Perhaps gcl does not run the dgemm
code so well?
I think you'll also get a somewhat better indication if you just compare
the times for the products (A.A) and dgemm(A,A), although I guess
mat_trace is probably not expensive.
When I run this with the CVS version of maxima on OSX with cmucl, I get
the following:
(%i24) A:adjacency_matrix(random_graph(900,0.003))$
Evaluation took 0.1700 seconds (0.2000 elapsed) using 18.729 MB.
(%i25) (A.A)$
Evaluation took 29.5900 seconds (34.5400 elapsed) using 37.189 MB.
(%i26) dgemm(A,A)$
Evaluation took 2.0500 seconds (2.1600 elapsed) using 117.610 MB.
So dgemm is about an order of magnitude faster than Maxima's matrix mult.
Also, your results don't make sense to me. dgemm does not make use of
any kind of sparseness, so the sparseness of the matrix shouldn't affect
the runtime in any way.
Ray