|
|
Ublas : |
Subject: Re: [ublas] Status of development /Benchmarks
From: Riccardo Rossi (rrossi_at_[hidden])
Date: 2013-12-07 13:50:02
Dear David,
all of the thins you poin out are nice ... if i could add something to the
wish list i woul like to add a few items:
1 - please mantain some sort of backward compatibility for people that do
not use internals... functions as noalias, prod innner_prod etc, while not
strictly needed do not make any harm and maintaining them woul make
people's life easier in the migration...
2 - clearly separate where openmp is going to be used (for example sparse
and large dense matrices) and where not ("tiny" matrices both in stack and
heap). this is important as one needs to avoid nested openmp parallelism
3 - it would be nice to have more c interoperability with the internals of
sparse matrices. this would make much easier to wrie wrappers
4 - consider pastix as a direct solver apart for mumps. it is really good
and actively developed...
good luck with your effort
ciao
Riccardo
On Sat, Dec 7, 2013 at 11:38 AM, David Bellot <david.bellot_at_[hidden]>wrote:
> Hi,
>
> it has been a long discussion we all had for many months now. Should we
> rewrite ublas from scratch or simply improve it.
> Joaquim and Oswin wants a brand new ublas
> Nasos was more in favor of improving it.
>
> I personally find very exciting the idea of writing something new, but
> ublas is very well known now. On the other hand, Eigen and Armadillo took
> the crown of the main C++ blas library in users' hearts.
>
> On my todo list for ublas, there are things that will require ublas to be
> deeply changed. At this stage, we can almost talk about a new library.
>
> Christmas is very close now, so maybe it's a good time to start talking
> about the features we wish for ublas and see if they can be implemented
> with the current version or if a new uBLAS 2.0 is necessary.
> After all, Boost::signal did the same a few years ago. We can definitively
> do the transition.
>
>
> I begin:
>
> - unified representation of vectors and matrices to represent the fact
> that a vector IS a matrix. Matlab does the same
> - automated use of different algorithm to let the compiler "chooses" the
> best implementation (if possible) and switch on SSE, distributed or whateve
> we need
> - implementation of solvers and decompositions algorithms
>
> and this is what Nasos and I think should be integrated too:
> 1. Matrix multiplication
> 2. Algorithms infrastructure (so that we can have real useful features)
> 3. 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
> 4. NEW DOCUMENTATION - examples and the rest
> 5. Incorporate some critical bindings (i.e. mumps bindings which is
> currently probably the most efficient smp and distributed open source
> linalg solver)
> 6. matlab binding?
> 7. distributed ublas
>
>
> Please add and ESPECIALLY, please tell me your view on the current
> infrastructure of uBLAS. It seems many people are not happy with the
> current "expression template" grammar.
>
> I'm open to everything
>
> Best,
> David
>
>
> On Thu, Dec 5, 2013 at 11:14 AM, Joaquim Duran <jduran.gm_at_[hidden]>wrote:
>
>> 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.
>
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: rrossi_at_[hidden]
>
-- Dr. Riccardo Rossi, Civil Engineer Member of Kratos Team International Center for Numerical Methods in Engineering - CIMNE Campus Norte, Edificio C1 c/ Gran Capitán s/n 08034 Barcelona, España Tel: (+34) 93 401 56 96 Fax: (+34) 93.401.6517 web: www.cimne.com