|
|
Ublas : |
Subject: Re: [ublas] Performance woes affecting ublas
From: David Bellot (david.bellot_at_[hidden])
Date: 2010-05-12 03:34:53
well, for the time being I'm working on documenting every single object and
function in doxygen. This will provide a full API documentation at least.
Then I'm thinking about writing tutorials for the beginners like I was. The
learning curve has been long and hard and I would like people to be able to
jump into ublas quickier.
What comes on top of my mind is that we need beginners and advanced users
examples with snippets of code and explanations in english. That would be
great. The lack of example, tips and tricks is a major concern about ublas
users.
Even simple things are most welcome: how to do simple operations, how to
implement common algorithms (that are not yet in ublas), how to do things
"like in matlab", what are the tricks to speed up this or that algorithm,
why my algorithm is faster in matlab than with ublas, and so on...
You can write things in pure ascii text, I will reformat everything then.
Cheers,
David
On Wed, May 12, 2010 at 09:26, Andrea Cassioli <cassioliandre_at_[hidden]>wrote:
> Hi David,
> it's good to know about uBlas documentation improving.....how can we
> help? It is a stupid question I know, but I'm pretty new in
> contributing on such projects.....
>
> Andrea
>
> On 5/12/10, David Bellot <david.bellot_at_[hidden]> wrote:
> > 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
> >
>
>
> --
> Andrea Cassioli
> _______________________________________________
> 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