|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: Vardan Akopian (vakopian_at_[hidden])
Date: 2010-05-18 22:06:55
On Thu, May 13, 2010 at 7:06 PM, Rui Maciel <rui.maciel_at_[hidden]> wrote:
>
> 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.
There is no single insult in my post. It's a simple (but strong) invitation
to show the code. If you're ranting about a huge performance problem, and
implying that it's inherent in the library and its design, the least you can
do is show some code _together_ with your original complaint. Your original
post was a complaint without any means for others to check/confirm/deny it.
And at the same time it had an implication that the grass is greener
everywhere else. Thus my characterization.
With the code attached here, this thread now acquires value, and can be
helpful to others. So my characterization does not apply anymore. However,
it served its purpose of bringing the code in.
> And the subject line is more than
> appropriate for the subject at hand.
I beg to differ. An appropriate line would have been something like "help in
achieving optimal performance for solving sparse systems". Which would be
much more in line with what you're trying to do and much more respectful to
the authors and users of the library. It would have also been helpful to
others in the future when searching this list for the same problems.
> 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.
>
Simple explanation: wrong/inappropriate usage of the library. See below.
>
> 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).
>
The main thing you might be forgetting or overlooking is that uBlas is an
implementation of BLAS (level 3). And this is the first phrase in the
official documentation. BLAS (and therefore uBlas) does not offer any of the
functions you listed. To be able to do inversions and solvers, ublas uses
the so-called bindings.
> 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.
>
The lack of good/extensive documentation is the known shortcoming of uBlas.
However, that does not mean that you should use features of library without
a clear picture of the data structures and the costs associated with them.
There is a reason why you picked compressed_matrix, instead of plain matrix,
or other types of sparse matrices (coordinate_matrix, etc). I assume that
was a conscious choice, so you must have given consideration about the
trade-offs between memory, access time, etc. Compressed matrix is a well
known structure used for decades in standard algorithms, and it's well known
that random access cannot be done in constant time with this structure. No
matter what library you use (yes, even eigen2), this property of compressed
matrix will not change. And this is exactly what I mean by the "wrong
usage".
>
>
> > 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.
I think this comes from your perceived notion of what uBlas is. Once it's
clear that uBlas is just BLAS, the obvious next question is, how does one
solve systems, etc with it. And the answer, which is _everywhere_ on this
forum is: bindings. I dare to say the majority of the posts on this lists
(at least recently) have been about bindings - either the old version 1, or
the new auto-generated version 2. And, unfortunately, bindings is not part
of boost yet, which is why it's a separate download. I'm surprised that you
have been using uBlas, and are subscribed to this list, yet you don't know
about bindings.
The point however is that, all those are valid questions, that you could
have asked and would have gotten quick answers to.
> 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.
>
Comparing uBlas (without bindings) and eigen2 is not an apples-to-apples
comparison: it's like saying "lapack is so much easier to use for solving
systems than blas". Comparing uBlas _with_ bindings is fair game though.
>
>
> So feel free to show how it is done and please do try to improve on the
> results, not through insults and absurd accusations.
>
Well, by saying "you may use whatever component is distributed with Boost's
official package", you exclude the bindings, and so you've constrained the
play-field to a point where the problem is meaningless. And again, you're
assuming that the "official uBlas package" is enough to solve your sparse
system. It's not. That's not its intended use. And of course I'm not going
to attempt to rewrite umfpack or other sparse system libraries or craft my
own. That would defeat the purpose of using uBlas and the rest of the
libraries. But if you are interested in giving bindings and umfpack a try,
give it a shot (now that you have the link to the umfpack doc), see how it
performs. And if you need help, ask nicely, and I promise I will help.
-Vardan