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".
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.