Boost logo

Ublas :

Subject: Re: [ublas] Anybody still there?
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2012-02-01 14:03:38


Yes. See the Eigen Benchmark:

I'm not sure how this behaves for different platforms, but i often get the
impression, that the code generated by ublas is not of a form which is
easy to vectorize. On top of that, uBLAS is slow by design. When you look
at what the library makes tick, it is obvious, that noalias(A)+=prod(B,C)
can't be fast. That's why there is an axpy_prod (which is also not optimal

Now i wanted to add some points to the flame wars:

1. I get the impression, that uBLAS is stuck between two different world
1.1 the "u" in uBLAS stands for "micro" and so it is limited in some sense
1.2 But uBLAS should still support everything which other linear algebra
libraries can do.

The result is, that it is easy to write expressions like

ublas::matrix<double> A,C;
ublas::compressed_matrix<double> B;

with arbitrary matrices A, B, C.

for which there doesn't exist an optimized compute kernel. So it is
possible to use the classes, but there is no active support for it.

>From my point of view one could remove like half of the code, optimize the
rest and would end up with an awesome linear algebra library where the "u"
doesn't stand for micro performance but: restricted feature set.

In my Opinion it would be sufficient to have a:
dense matrix/vector
one type of sparse matrix/vector
all proxies without slices.
rest optional.

2. The other point is, that it is quite hard to add fast compute kernels
to the library in any way. I'm at the moment writing my own "fast_prod"
which is based on code of the old numeric bindings. But it is really tough
to analyse what the arguments are doing: Should i copy the expression into
a temporary? Is the argument sparse? If yes, is it "aligned" or is it
something like a column of a sparse row_major matrix which you can't use
in any meaningful way?


I like ublas. But i see myself at the moment more coding against it's
limitations than doing anything else.

Still i would like to contribute if there is a way to help out :)


ps: I don't see a Problem in the distinction between vector/matrix it is a
very good way to find out which types of algorithms to use...

> On Wed, Feb 1, 2012 at 9:29 AM, David Bellot <david.bellot_at_[hidden]>
> wrote:
>> - be faster than eigen and armadillo: ok that one is gonna be pretty
>> hard
>> :-D
> Tough question: Does this mean armadillo / eigen have better
> performance than ublas presently ?
> R.
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> Sent to: Oswin.Krause_at_[hidden]