|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: Rui Maciel (rui.maciel_at_[hidden])
Date: 2010-05-13 22:06:44
Vardan Akopian wrote:
> Hi Rui,
>
> How about posting the code that was taking 6 minutes with uBlas and now
> takes 5 seconds with eigen.
> Without an example of code where library X significantly outperforms uBlas,
> this thread has no value and is borderline trolling.
> Otherwise, if you are actually asking for help in optimizing your uBlas
> based code, you should choose a more appropriate subject line.
First of all, do you really believe that throwing insults around, making
baseless allegations and complaining about subject lines will solve any
problem? I don't believe it will. And the subject line is more than
appropriate for the subject at hand. If you don't agree then please explain
how a >6min run time to build and solve a small system of linear equations
problem is a perfectly acceptable result when you just find out that some other
alternative achieves the same thing with incomparably less effort invested in
it in around 5 seconds.
Having said that, I can do better than posting "an example of code". I'll
provide you, Vardan, with a trimmed down, benchmark version of my FEM code
which compares the library which I'm currently using (Eigen2) with uBlas. You
can test it for yourself and tweak the uBlas version with every single trick
you can get out uBlas' manual and you may use whatever component is
distributed with Boost's official package. Once you are happy with it you are
more than welcomed to share both the running times and your tweaks so that
others can not only learn from it but also be able to objectively compare the
results.
As a starting point, as uBlas doesn't offer basic operations such as
determinants, matrix inversions and sparse matrix solvers, I've took the
liberty of pasting custom routines which were either posted in this very same
mailing list as acceptable implementations (determinant and matrix inversion)
or I've developed myself (conjugate gradient solver).
To start things off, I'll post the run times that I've got from both versions:
Eigen, the first run comparing Eigen's default sparse matrix solver with uBlas
with a hand-made conjugate gradient method and the second run comparing only
matrix-vector algebraic opertations and matrix assignments. The results are
as follow:
<run with solver>
rui_at_kubuntu:benchmark$ make test
./test.sh
Testing eigen...
Building the FEM equation
Solving the FEM equation
Done.
real 0m5.254s
user 0m5.170s
sys 0m0.060s
Testing ublas...
Building the FEM equation
Solving the FEM equation
Done.
real 1m0.298s
user 1m0.150s
sys 0m0.140s
</run>
<run without solver>
rui_at_kubuntu:benchmark$ make test
./test.sh
Testing eigen...
Building the FEM equation
Solving the FEM equation
Done.
real 0m3.489s
user 0m3.490s
sys 0m0.000s
Testing ublas...
Building the FEM equation
Solving the FEM equation
Done.
real 0m11.006s
user 0m10.950s
sys 0m0.030s
</run>
It isn't necessarily fair to compare my cg solver with an officially distributed
solver which was developed with a component's capabilities in mind. Yet, as
uBlas doesn't provide any solver in the official distribution, nor is anything
mentioned in the documentation, and as iterative solvers don't rely on
directly accessing the matrix coefficients then, as a starting point, it isn't
that bad of a comparison. Even so, 5 seconds Vs 1 minute isn't exactly a
stellar result. So you have more than enough legroom to improve uBlas run
time.
And as a side note, the 6 minutes were taken from Cholesky and Gauss with
partial pivoting directly applied on a compressed_matrix<>. As it was
recently explained, that isn't a smart combo due to compressed_matrix<>'s
limitations derived from the time it takes to directly access it's coefficients.
Yet, the only reason that led me (and quite possibly a considerable number of
others like me) to use it any way is that this small but extremely important
fact is no where to be seen in the documentation.
> As to examples for using uBlas to solve sparse systems, you can do a search
> on umfpack bindings for uBlas. Documentation for v1 bindings:
> http://boost-sandbox.cvs.sourceforge.net/*checkout*/boost-sandbox/boost-san
> dbox/libs/numeric/bindings/umfpack/doc/index.html
See, this is exactly one of the major problems affecting uBlas. If you happen
to search for umfpack on uBlas' docs[1], you get zero results. This isn't
mentioned anywhere in the documentation. Furthermore, your proposed solution
comes in the form of an obscure extra component which not only isn't included
in uBlas' official package but also resides in an even more obscure CVS
repository. This cannot possibly be seen as a reasonable solution, specially
if other alternatives are already complete, don't force the users to rely on
obscure, practically inaccessible add-ons and, as if this wasn't enough, their
default offering already runs things at a fraction of both time and effort when
compared to uBlas' offer.
So feel free to show how it is done and please do try to improve on the
results, not through insults and absurd accusations.
Rui Maciel