|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: Andrea Cassioli (cassioliandre_at_[hidden])
Date: 2010-05-10 13:09:15
Hi Rui,
I must agree with you about the lack of performance of uBlas also for
small sparse matrices. I have experienced similar problems in
performing simple matrix-vector products, but in my case I could
rewrite my code to explictly perform the computation.
The timing you claim are indeed impressive, but I more fair comparison
should be done using uBlas in the proper way (something small
differences in coding result in great saving of time), but I do agree
that the documentation is an actual problem for the uBlas community.
Andrea
On 5/10/10, Rui Maciel <rui.maciel_at_[hidden]> wrote:
> I've just managed to migrate a small finite element application that I'm
> writing from ublas to eigen and I have to say that I've saw an abysmal
> difference in performance.
>
> I've migrated my code in the following two steps:
>
> The first one consisted in migrating the global stiffness matrix, global
> nodal
> force vector and solver (in effect, the part that dealt with the K*d=f
> equation) from ublas and custom code to eigen. In short, this migration
> consisted in replacing ublas' compressed_matrix with eigen's
> DynamicSparseMatrix and replacing ublas dense vector with an object of
> eigen's
> Matrix<double, Dynamic,1> class.
>
> As a result, this step alone lead my small pet program to go from taking
> over
> 6 minutes to run the analysis down to around 20 seconds. Granted,
> I had implemented the solvers myself without much info concerting the inner
> workings of ublas' components, which means that they certainly suffered from
> performance problems. Nonetheless, I've implemented 3 different solvers
> (Gauss
> factorization with partial pivoting, Cholesky decomposition and conjugate
> gradient method) and all three solvers took grossly the same order of time
> to
> solve a given system, including the cg method which is basically a series of
> algebraic operations.
>
> Having finished that step I've moved on to migrate the remaining ublas code
> to
> eigen. The second part consisted of a hand full of dense matrices which
> were
> subjected basically to a series of matrix assignments and multiplications,
> along with the inversion and the calculation of the determinant of a 3x3
> matrix. This step sliced the time it took to run the analysis from around
> 20
> seconds down to 5 seconds.
>
> So, summing things up, migrating from ublas and a set of hand-made solvers
> to
> eigen made it possible for my program to go from taking over 6 minutes to
> solve a simple problem to taking around 5 seconds to perform the same task.
>
> Again, I acknowledge that certainly my sloppy code had a lot to do with that
> abysmal performance penalty experience in the ublas version of my program.
> Nonetheless this problem could be at least avoided in part if the
> documentation was improved in key areas, such as common gotchas associated
> with sparse matrices and the efficiency associated with basic operations.
>
> Also, through my migration it was also possible to notice that ublas is far
> from efficient even when used to perform simple tasks such as products
> between
> smallish dense matrices (from 3x3 to 81x6) and between dense matrices and
> dense vectors, a aspect of ublas whose tuning was supposed to be focused on.
>
> No matter how sloppy any code is, if your code takes a 3.4x performance
> penalty just for performing basic tasks such as products between small dense
> data types... Well, that is a good sign that something isn't working right.
>
> I'm aware that there were no promises made regarding efficiency but a
> difference
> of this magnitude leaves a lot to be desired.
>
>
> Rui Maciel
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: cassioliandre_at_[hidden]
>
-- Andrea Cassioli