|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: Riccardo Rossi (rrossi_at_[hidden])
Date: 2010-05-10 12:53:35
Hi Rui,
this is just to say that we have a pretty large finite element
code heavily based on ublas ... and that in our benchmarks it is
competitive to fortran based implementations.
although i am pretty sure that for small dense matrices other libraries
are far more efficient, i am pretty sure that this performance penalty
does not sussist for large sparse matrices.
greetings
Riccardo
On Mon, 2010-05-10 at 17:47 +0100, Rui Maciel 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: rrossi_at_[hidden]