Re: [ublas] Question on ublas performance (resending as subscriber).

Subject: Re: [ublas] Question on ublas performance (resending as subscriber).
From: Rui Maciel (rui.maciel_at_[hidden])
Date: 2010-04-21 05:45:45

Jörn Ungermann wrote:
> Hi Sunil,
> 
> this is likely not a problem of uBLAS, but one of the principal problems
> of using sparse matrices. Depending on the type of matrix either random
> access or multiplication performance is efficient.
> For the compressed_matrix, random access is rather costly unless you
> can control the way in which elements are added to the matrix. If you
> can assemble the (row_major) compressed_matrix row-by-row with ascending
> column indices, this should take no time at all.
> If you can't do this, use a different matrix type for assembly, e.g.
> mapped_matrix (which offers efficient random access, but bad
> computational performance) and construct the compressed_matrix from
> there.
> 
> See Gunter Winkler's page for details:
> http://www.guwi17.de/ublas/matrix_sparse_usage.html

You may be right in the technical details, that, when relying on uBLAS, using 
a certain matrix data type a certain way will end up being slower than some 
other alternative.

Nonetheless, it is a uBLAS problem and a serious one at that.  The 
documentation doesn't mention anything about how slow some operations on 
certain data types (which incidentally may even come out as the "right way" of 
implementing some problems) can be when compared to other alternatives, it 
doesn't provide any test case or benchmark providing a quantitative assertion 
of how a method fair when compared to the alternatives and, probably more 
importantly than all, the example page you just provided indicates that 
possibly the right way of doing this sort of task heavily relies on 
undocumented features.  

That absence of information is a serious problem with uBLAS.  It invariably 
leads uBLAS newbies to go off writing their software completely unaware of how 
bad they are tailoring their program's performance to be.  The newbies may 
read the documentation from top to bottom, they may flawlessly implement the 
linear analysis bit but, as the document is incomplete and omits fundamental 
details which otherwise go through unnoticed, the newbies will only realize 
how painstakingly slow uBLAS gets to be way after they finish writing their 
program and start "stress-testing" it.  And by that time it may be too late to 
do anything about it.

This is a very serious problem which has serious implications on how uBLAS is 
being used, how the programs which rely on uBLAS tend to perform and, as a 
direct consequence, how the reputation of uBLAS is being built. 

Rui Maciel