|
|
Ublas : |
Subject: Re: [ublas] GSOC 2013
From: oswin krause (oswin.krause_at_[hidden])
Date: 2013-03-24 09:27:51
Sorry, I don't want to spam.
Here a list of suggestions which I find way more important than unifying
matrices and vectors:
1. change the way iterators work for matrices, as already outlined here
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?UBLAS_Matrix_Iterators
over 6 years ago.
The reason why this should be important? I have an application where I
need to compute a lot of distances between vectors and matrix-rows (in
row-oriented matrices). If the arguments are sparse (and I use a
compressed matrix), i am more than factor 3 slower than the simple
for-loop using the internal arrays of the compressed matrix. The main
bottle neck is CompressedMatrix::find for the two queries of the
begin/end iterators, which should in this case be only 2 memory lookups
but is ridiculously slow in the ublas design. But even afterwards, this
leads to a much slower iterator than just iterating the arrays.
When I wrote a workaround wrapper for that which takes a matrix-row of a
compressed matrix and implements the sane iterator for that, i get the
expected speed-up(minus a small overhead for the wrapper itself...).
2. change the way matrix-expressions are evaluated. In the current
iterator based design, not even transposing a matrix can be done fast. I
am currently playing a round with a design which interprets expressions like
A+= 3.0*subrange(expression,a,b,c,d)
as
expression.plusAssignTo(A,a,b,c,d,3.0);
and suddenly everything can be implemented very easy and fast (and also
very general).
3. proxies of "real" vectors/matrices(i.e. vectors which can be left
hand side arguments) should make use of the memory layout of the
underlying vector/matrix. The created wrappers should be interchangeable
when the underlying object has the same memory layout. That means taking
a matrix row of a row-major dense matrix should lead to the same proxy
as taking a subrange of a vector. Moreover a vector should be implicitly
convertible to it's wrapper type.
reason:
struct Foo{
virtual void doSomething(dense_vector_proxy<double> const& wrapper);
};
Foo foo;
blas::matrix<double> m;
blas::vector<double> v;
foo.doSomething(row(m,0));
foo.doSomething(v);
This is of course only my opinion, but these are the things which cost
me the most time right now.