|
|
Ublas : |
Subject: Re: [ublas] forking ublas?
From: oswin krause (oswin.krause_at_[hidden])
Date: 2013-04-10 14:10:31
Hej Nasos,
Thanks for your answer. Here is a short list of the major things that i
had to workaround. Most is sparse related, but there is also a bit of
things wrong with dense vectors/matrices, I did not use the rest of
ublas, though.
1. compressed matrix iterators are super inefficient. I use row-major
matrices and only want iterators to the beginning/end of the rows and
iterate over them which I get by
matrix_row<compressed_matrix<double,row_major> const > r=row(matrix,i);
const_iterator pos = r.begin();
const_iterator end = r.end();
and than iterate once over them. this is roughly factor 3 slower than
doing the same on the pure c-array. Already acquiring the iterators took
roughly as long as the whole sparse operation on the c-array.
I workarounded this by using a class which could represent the row much
more efficiently, ie.
MySparseProxy r = row(matrix,i);//bit of template magic here.
const_iterator pos = r.begin();
const_iterator end = r.end();
which got me to c-performance again.
The reason is that the interface does not allow for fast iterators as
iterator duality needs to be preserved.
Also it seems to be possible to get iterators to non-existent positions
which requires a lot of additional logic.
I understand, that sparseness is hard when it should work with row(...)
column(...) and subrange(...) but for me it is
a major burden and it is near to being unusable.
2. inner_prod is slow for sparse vectors.
Nearly the same as above only that inner_prod didn't even reach
c-performance with my fast iterators. The algorithm used by ublas has a
bad assumption about how the values in sparse-vectors are distributed
which makes the algorithm slow. the most simple algorithm is the way to
go here.
3. axpy_prod is incomplete. Now, i know what the u in ublas stands for.
however, not even the dense case is fully
implemented which forced me to implement my own fast_prod which for
example calls
C+=prod(A,B) when A is row major and B is column major, as there is no
case distinction for this in axpy_prod.
4. vector_unary (or in general all expression taking a functor) only
allow for functors with a static apply() function.
There is also an undocumented issue with sparse vectors when the functor
does not have the property f(0)=0 i.e. operator() gives the correct
result while the iterators just skip these values (thus
cout<<exp(empty_sparse_vector) implemented with vector_unary prints as
[0,0,0,0,0])
there are a few smaller issues, but they ar not that important as the
ones above.
On 10.04.2013 20:04, Nasos Iliopoulos wrote:
> Oswin,
> I don't think there are any requirements in place in order to fork
> uBlas, you can just go ahead and make your own project based on it. I
> suspect thought that the maintainers would be happy to provide a
> convenient versioning environment (through github maybe?) for people
> that want to contribute in say providing new algorithms or improving
> on existing ones, while retaining the core functionality.
>
> Can you give an example of what functionality you had to rewrite?
>
> Best,
> Nasos
>
>
>
> On 04/07/2013 01:50 AM, oswin krause wrote:
>> Hi,
>>
>> I recently came to the conclusion that for me it does not make sense
>> to use ublas any more.
>>
>> I found my self reimplementing a lot of functionality that is already
>> in-place because it was implemented poorly / can not be implemented
>> fast in the current interface. The only reason we stay with ublas in
>> our project is that, in theory, it is one of the most feature rich
>> libraries out there (while having a mu in its name) and we use a lot
>> of the functionality, especially sparse-dense matrix operations etc
>> (and no, eigen is not an option as the interfaces are way to
>> different to port the whole project again and eigen has a lot of
>> restrictions for sparse matrices.)
>>
>> The recent discussion about the GSOC project lead me to fear that my
>> workaround code will break, while the library itself would still not
>> be in a state that I can just replace the workarounds with ublas core
>> functionality. At some point I have to think about my PhD thesis and
>> for this i would like things to get better over time (e.g.
>> workarounds vanish and I don't need to profile ublas code all the
>> time). I don't see this happening and I am now at the point where I
>> know the library good enough to replace functionality directly
>> instead of adding workarounds.
>>
>> So can we fork ublas? and if yes: what are the conditions?
>>
>> Greetings,
>> Oswin
>> _______________________________________________
>> ublas mailing list
>> ublas_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: Oswin.Krause_at_[hidden]