|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: David Bellot (david.bellot_at_[hidden])
Date: 2010-05-12 03:24:02
yes the documentation is a major issue and ... oh boy... the list of tasks
is so long.
I'm making progress anyway... every single day :-)
That was the good news of the day. ;-)
:-D
Cheers,
David
On Mon, May 10, 2010 at 19:22, Nasos Iliopoulos <nasos_i_at_[hidden]> wrote:
> 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. See how.<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: david.bellot_at_[hidden]
>
-- David Bellot, PhD david.bellot_at_[hidden] http://david.bellot.free.fr