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
> See Gunter Winkler's page for details:
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
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
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.