On 5/12/10, David Bellot <
david.bellot@gmail.com> 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@hotmail.com> 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@gmail.com
>> > To:
ublas@lists.boost.org
>> > 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@gmail.com> 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@lists.boost.org
>> > >
http://lists.boost.org/mailman/listinfo.cgi/ublas
>> > > Sent to:
cassioliandre@gmail.com
>> > >
>> >
>> >
>> > --
>> > Andrea Cassioli
>> > _______________________________________________
>> > ublas mailing list
>> >
ublas@lists.boost.org
>> >
http://lists.boost.org/mailman/listinfo.cgi/ublas
>> > Sent to:
nasos_i@hotmail.com
>>
>> ------------------------------
>> Hotmail is redefining busy with tools for the New Busy. Get more from your
>> inbox. See