|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2010-05-10 13:22:35
Theoertically, ublas should be about 2(for double precision)-4(for single precision) times slower in computational (not memory) intensive algorithms with respect to libraries using vectorization (like eigen2). If you find ublas performing worse than, it is probable that something else is going on.
It is a fact though that documentation is a major issue, but it looks that it is being taken care of lately.
Best
Nasos
> Date: Mon, 10 May 2010 19:09:15 +0200
> From: cassioliandre_at_[hidden]
> To: ublas_at_[hidden]
> Subject: Re: [ublas] Performance woes affecting ublas
>
> 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
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: nasos_i_at_[hidden]
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2