Re: Status of development /Benchmarks

Dear all,

I think that al stuff pending of merge listed by David, should be merged
and migrate to uBlas 2.0 and while uBlas 2.0 is in development/maintenance
then design from scratch uBlas 3.0.

My two cents!!

Joaquim Duran


2013/12/2 oswin krause <[email protected]>

>  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 <
> [email protected]> 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 <
>> [email protected]> 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
>>> [email protected]
>>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>>> Sent to: [email protected]
>>>
>>
>>
>>
>>  _______________________________________________
>> ublas mailing [email protected]://lists.boost.org/mailman/listinfo.cgi/ublas
>>
>> Sent to: [email protected]
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> [email protected]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: [email protected]
>>
>
>
>
> _______________________________________________
> ublas mailing [email protected]://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]
>
>
>
> _______________________________________________
> ublas mailing list
> [email protected]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]
>