- I am currently working with a lot (~ 20) of matrices wich are

relatively big (~ 2250x2250) because of the number of matrices, I must

use sparse or compressed matrice.

My problem is the speed for prod and prec_prod between two matrices.

I wonder if there is any way at all to speed it up...

I would have used ATLAS bindings but they are only for dense matrices

(gemm).

I have also looked at axpy_prod but I did not find any relevant

documentation/examples so I dont know if I could use this instead...

Here is a small code sample :

--------------------------------------------------------------

typedef ublas::compressed_matrix<double, ublas::row_major>

CompressedMatrixRM;

typedef ublas::compressed_matrix<double, ublas::column_major>

CompressedMatrixCM;

CompressedMatrixRM a(2250,2250);

CompressedMatrixCM b(2250,2250);

CompressedMatrixCM c(2250,2250);

// This is repeated about 15 times with similar matrices

c = prec_prod(a, b);

---------------------------------------------------------------

Thanks in advance,

Simon Michaud - For me, axpy_prod was the solution to a similar problem with many compressed_matrix*vector products - orders of magnitude in speed, and also the expected O(N) behavior with axpy_prod.

However, I came across the correct call to axpy_prod only with help form Joerg (thanks again) and some luck. I don't know about documentation either, but axpy_prod is certainly worth a closer look.

Julius

At 02.03.2004 Tuesday 17:20, you wrote:

`I am currently working with a lot (~ 20) of matrices wich are`

relatively big (~ 2250x2250) because of the number of matrices, I must

use sparse or compressed matrice.

My problem is the speed for prod and prec_prod between two matrices.

I wonder if there is any way at all to speed it up...

I would have used ATLAS bindings but they are only for dense matrices

(gemm).

I have also looked at axpy_prod but I did not find any relevant

documentation/examples so I dont know if I could use this instead...

Here is a small code sample :

--------------------------------------------------------------

typedef ublas::compressed_matrix<double, ublas::row_major>

CompressedMatrixRM;

typedef ublas::compressed_matrix<double, ublas::column_major>

CompressedMatrixCM;

CompressedMatrixRM a(2250,2250);

CompressedMatrixCM b(2250,2250);

CompressedMatrixCM c(2250,2250);

// This is repeated about 15 times with similar matrices

c = prec_prod(a, b);

---------------------------------------------------------------

Thanks in advance,

Simon Michaud

`Yahoo! Groups Links`- To visit your group on the web, go to:
- http://groups.yahoo.com/group/ublas-dev/
- To unsubscribe from this group, send an email to:
- ublas-dev-unsubscribe@yahoogroups.com
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Julius Muschaweck

_____________________________________________________

OEC AG

Paul-Gerhardt-Allee 42

81245 Muenchen, Germany

Phone: +49 89 820050-30

Fax: +49 89 820050-41

e-mail: <muschaweck@...>

Internet: www.oec.net

______________________________________________________ - Zitat von ssmmiicchhaauudd <simon.michaud.1@...>:

> I am currently working with a lot (~ 20) of matrices wich are

The syntax of axpy_prod is:

> relatively big (~ 2250x2250) because of the number of matrices, I must

> use sparse or compressed matrice.

> I have also looked at axpy_prod but I did not find any relevant

> documentation/examples so I dont know if I could use this instead...

#include "operation.hpp"

axpy_prod( A, X, Y, clear);

which computes:

if (clear)

{ Y = A * X; }

else

{ Y += A * X; }

axpy_prod is specialized for compressed_matrix * (dense-)vector which gives best

performance but can also be used for (any sparse) matrix * (any sparse) matrix.

But inserting elements into sparse matrices may be very slow.

Maybe you should think about using

#include "vector_of_vector.hpp"

generalized_vector_of_vector<double, row_major, compressed_vector<double> >

or

generalized_vector_of_vector<double, row_major, coordinate_vector<double> >

up to now axpy_prod does not use Y.push_back() or Y.insert() if Y is empty which

could further speed up computation.

Again: Please have a look at my page

https://www-user.tu-chemnitz.de/~wgu/ublas/matrix_sparse_usage.html

(the section about the "residual")

mfg

Gunter

PS: Looks like my page should go to the documentation ASAP ;-) - Thanks, that solved my problem, I went from 224 seconds(prec_prod) to

9 seconds(axpy_prod).

Not to be rude or anything (your are all doing great work on uBlas),

but would an API documentation, with Doxygen for example, be more

useful and easier to read than the current documentation format. It

could also show API for undocumented methods.

And thanks again...

Simon Michaud

--- In ublas-dev@yahoogroups.com, Gunter Winkler <guwi17@g...> wrote:

> Zitat von ssmmiicchhaauudd <simon.michaud.1@e...>:

>

> > I am currently working with a lot (~ 20) of matrices wich are

> > relatively big (~ 2250x2250) because of the number of matrices, I

must

> > use sparse or compressed matrice.

>

> > I have also looked at axpy_prod but I did not find any relevant

> > documentation/examples so I dont know if I could use this instead.

..

>

> The syntax of axpy_prod is:

>

> #include "operation.hpp"

> axpy_prod( A, X, Y, clear);

>

> which computes:

> if (clear)

> { Y = A * X; }

> else

> { Y += A * X; }

>

> axpy_prod is specialized for compressed_matrix * (dense-)vector

which gives best

> performance but can also be used for (any sparse) matrix * (any

sparse) matrix.

> But inserting elements into sparse matrices may be very slow.

>

> Maybe you should think about using

> #include "vector_of_vector.hpp"

> generalized_vector_of_vector<double, row_major,

compressed_vector<double> >

> or

> generalized_vector_of_vector<double, row_major,

coordinate_vector<double> >

>

> up to now axpy_prod does not use Y.push_back() or Y.insert() if Y is

empty which

> could further speed up computation.

>

> Again: Please have a look at my page

> https://www-user.tu-chemnitz.de/~wgu/ublas/matrix_sparse_usage.html

> (the section about the "residual")

>

> mfg

> Gunter

>

> PS: Looks like my page should go to the documentation ASAP ;-)