|
|
Ublas : |
Subject: Re: [ublas] Status of development /Benchmarks
From: oswin krause (oswin.krause_at_[hidden])
Date: 2013-12-02 04:32:53
Hi David,
Yes at a point i thought about contributing to uBLAS. But there are two
problems with it that are making it hard to develop.
1. There is no real consensus of what uBLAS should be targeted at. Right
now I have the feeling that it should be more or less like Eigen: be
applicable to every use case out there. And this is hard. Most of Eigen
looks to me like a big mess. This is because it must behave differently
in the cases of small, big and very big problems. Right now uBLAS has
only a good performance for small dense problems and I am mostly only
interested in the middle category. And the last time i proposed changes
I got nearly no support but fire from the "small" and "very big" guys.
This makes it quite unattractive for me to propose further changes.
2.
>
> So please, feel free to propose anything you think is relevant to
> uBLAS. At some point we even thought about rewriting a big part of
> uBLAS and call it uBLAS 2 (and go through the peer review again,
> etc...). Well, I think uBLAS can evolve smoothly rather than having a
> big revolution.
I don't think that this is possible without iteratively annoying all
uBLAS users who actually use things like loops over matrix elements and
the other low level interfaces. I had to rewrite the sparse interface
completely(and i am still not sure that i have done that right) as well
as the iterator interface. I tried to do it smoothly but I nevertheless
broke it 3 times.
The next problem, again sparse, is that there are 3 different formats
supported by uBLAS. It is hard to write algorithms for it, because the
three formats need to be treated differently. But in a smooth evolution
we can't really throw out stuff, especially if there is no 1:1 replacement.
I think you can find such issues in a lot of parts, as you said, uBLAS
is old. There are more things, like that you might want to change the
way expressions are evaluated so that things like
noalias(A)+=prod(B,C)+D;
are fast and don't require intermediate results in prod().
I think a full rewrite from scratch is required to get rid of all the
old burdens. While a review process of course is a bit annoying it might
actually help in developing it to something that is actually useful :).
(And honestly i doubt that uBLAS as is would pass a review.)
Best,
Oswin
On 29.11.2013 13:55, David Bellot wrote:
> Hi Oswin,
>
> well, I'm just the maintainer of uBLAS, not the owner and for sure not
> the first developer as it was already an old project when I took over
> it. I believe any contributions is welcome and honnestly so many
> things can be changed in uBLAS. It's getting a little bit old.
> So that's why I'm always happy to have new contributions. That's also
> the reason I wanted to have GSOC projects this summer and I think it
> has been a good thing.
>
> I didn't know Shark was your library ! Well done. It's a good library.
> I'm especially interested in your implementaion of RBM.
>
> So please, feel free to propose anything you think is relevant to
> uBLAS. At some point we even thought about rewriting a big part of
> uBLAS and call it uBLAS 2 (and go through the peer review again,
> etc...). Well, I think uBLAS can evolve smoothly rather than having a
> big revolution.
>
> The automatic ATLAS binding is definitively something I want !!!!
>
> Best,
> David
>
>
> On Fri, Nov 29, 2013 at 12:04 PM, oswin krause
> <oswin.krause_at_[hidden]
> <mailto:oswin.krause_at_[hidden]>> wrote:
>
> Hi David,
>
> Thanks for the fast reply. There might be a misunderstanding: I
> don't have any code here that is ready for uBLAS. The story goes
> back to approximately spring where it was decided to improve
> uBLAS. I decided to part ways because of our differences in how
> uBLAS should look like (and since it is your library it is of
> course your right to choose!). So I rewrote the whole thing (or
> better: the parts that i needed, that is dense and sparse algebra,
> no banded matrices) and now got a 16000 LOC subset of uBLAS with
> most of the functionality (and sometimes more) and automatic ATLAS
> bindings for fast_prod etc.
>
> Now i wanted to come back and compare the different approaches and
> see whether I could adopt some of your changes as well as maybe
> port some of my code back to uBLAS.
>
> So once most of the new features are there, i would be happy to
> compare! You would also get a direct benchmark against atlas if
> you like.
>
> My version is unfortunately not standalone yet because of
> $REASONS. Also looking at your changes, i doubt that the libraries
> are compatible, for example because I overloaded op* and op/ for
> element-wise operations ( I need them so often, element_prod and
> element_div just does not cut it...)
>
> But if you like you can have a look at it here
>
> (most of ublas functionality minus systems of equations and
> algorithms)
> http://sourceforge.net/p/shark-project/code/HEAD/tree/trunk/Shark/include/shark/LinAlg/BLAS/
>
> (and systems solver + algorithms (wip))
> http://sourceforge.net/p/shark-project/code/HEAD/tree/trunk/Shark/include/shark/LinAlg/
>
> Best Regards,
> Oswin
>
>
> On 29.11.2013 12:40, David Bellot wrote:
>> Hi,
>>
>> the latest version is indeed on github. We didn't commit many
>> things this year so far. We are talking (slowly, I must admit,
>> please blame me not the others) about new features and changes:
>>
>> (1) integrating GSOC 2013 in the main branch
>> (2) removing the vector object to replace it by a new one that
>> will be a matrix and therefore implement a real row of column vector
>> (3) Matrix multiplication with operator* valid for all standard
>> operation (vector, matrix, etc...). It is related to (2)
>> (4) Algorithms infrastructure (so that we can have real useful
>> features)
>> (5) Matrix/vector views for interoperability <- I think this is
>> ultra critical because now ublas is monolithic in the sense that
>> you have to use it everywhere you manipulate data. This would
>> really help into letting people for example have a list of
>> vectors (they are plotting) and ublas working on top of that to
>> do for example transformations
>> (6) NEW DOCUMENTATION - examples and the rest. The current one is
>> ... old
>> (7) Incorporate some critical bindings (i.e. mumps bindings which
>> is currently probably the most efficient smp and distributed open
>> source linalg solver)
>> (8) Matlab binding? Matlab I/O etc... Well same thing with R, csv
>> files, etc... Bindings and I/O in general are pretty poor
>> (9) Distributed ublas (GSOC'13)
>>
>>
>> I'm really interested seeing your benchmark. Maybe you can join
>> the github ublas project as well. If you give me your github id I
>> can associate it with the project and you can push your code.
>> Practically speaking, there is a ublas project on github which is
>> a copy a the main boostorg/ublas project. And there are many
>> branches for each project that people can use.
>>
>> Links you can be interested in:
>> https://github.com/uBLAS/ublas/wiki
>>
>> The workflow that we will follow (as also suggested in boost
>> mailing list) is:
>> http://nvie.com/posts/a-successful-git-branching-model/
>> with the difference that we have two "masters" i.e. one in
>> ublas_develop (which is our working master) and one that will be
>> always in sync with the latest boost release.
>>
>> And last but not least, there are a few changes for supporting
>> IDE. In fact, that would be good if people can contribute more.
>> I'm a vi user only, so I need others' skills for that. QTCreator
>> is on its way. Ideally, if we can have some sort of support for
>> the main IDE, on top of my mind: Eclipse, Netbeans, Visual
>> Studio, Anjuta, KDevelop, etc...
>>
>> Best regards,
>> David
>>
>>
>>
>> On Fri, Nov 29, 2013 at 9:04 AM, oswin krause
>> <oswin.krause_at_[hidden]
>> <mailto:oswin.krause_at_[hidden]>> wrote:
>>
>> Hi,
>>
>> I am interested in the current development status of the
>> library. is there the possibility to get the latest version
>> somewhere? I tried to find a working branch on
>> https://github.com/boostorg/ublas but could only find changes
>> older than half a year.
>>
>> I am interested in Benchmarking the "new" ublas against "my"
>> reimplemented subset (think about my personal summer of code :) )
>>
>> Greetings,
>> Oswin
>> _______________________________________________
>> ublas mailing list
>> ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: david.bellot_at_[hidden] <mailto:david.bellot_at_[hidden]>
>>
>>
>>
>>
>> _______________________________________________ ublas mailing
>> list ublas_at_[hidden] <mailto:ublas_at_[hidden]>
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>>
>> Sent to:Oswin.Krause_at_[hidden] <mailto:Oswin.Krause_at_[hidden]>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden] <mailto:ublas_at_[hidden]>
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: david.bellot_at_[hidden] <mailto:david.bellot_at_[hidden]>
>
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: Oswin.Krause_at_[hidden]