|
|
Ublas : |
Subject: Re: [ublas] Status of development /Benchmarks
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2013-12-09 09:05:44
I would just like to make a few remarks here. I also integrated some of
the ideas that people posted on the list up to now.
On 12/07/2013 05:38 AM, David Bellot 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.
>
This is not correct. I only suggested that in order to be able to meet
the GSOC deadlines.
> 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
>
Since I aided in compiling this list I will just point out some more
details on the basic features I believe uBLAS 2.0 should focus on:
1. Expression templates mechanism rewrite : probably go with boost::proto
2. Unified matrix - vector classes. We could even make this a tensor
super-class that I would prefer in the end. The critical issue would be
to make a graceful traits model (maybe a traits object that bundles
together all relevant information, rather than a bunch of properties the
current traits model support)
3. Separation of data storage from matrix/vector/tensor classes to break
the current monolithic model and enable interoperability with other
libraries (i.e. graphics, storage, gui, algebra, etc.). A model like
what is used in boost::gil is very appealing to me. Doing that for
example would be ultra easy to make an ublas/octave/matlab wrapper.
4. Parallel implementation: The C++11 threading model can be adopted
instead of openMP. It will be a little bit more involved to setup and it
may require some state in the form of a singleton. To avoid this we will
need some sort of interface to initialize threads pools and provide
algorithms with the thread data.
5. Distributed uBlas. I consider this critical since it seems that large
computations will move to clusters in the future (especially with the
availability of all those inexpensive cloud computational cluster services).
6. Algorithms infrastructure (from fast BLAS to general purpose algebra
and beyond): I think this is very critical.
7. DENSE MATRIX MULTIPLICATION: We already have a good implementation
from GSOC, that needs some face lifting before it gets into production.
8. Bindings (Migration of the current ones and extension to other
popular packages like MUMPS, PARDISO and other solvers)
9. Enable syntax similar to MATLAB or even extend it by using summation
convention and Einstein notation. Under such a model, algorithms will be
ultra easy to write (although in many cases not optimal with respect to
the CPU architecture). Imagine for example the multiplication:
ublas2::index i,j,k;
A(i,j) = B(i,k)*C(k,j); // Automatic looping over i,j and summation over
the rhs 'k' index.
and that would be it!
// note indexes can be reused since they are merely placeholders
ublas2::index m(1,10);
A(m,j) = B(m+20, j)*C(m,j);
For such a plan the critical path would be:
0a. Decide what type of data uBlas will be operating on and start with
the traits mechanism. Because all algorithm dispatching will be based on
it it should be carefully designed. Of course a very first trivial
interface would be to build on top of the current one:
typedef ublas2::matrix<double> my_matrix:
typedef my_matrix::traits traits;
with
template <typename Storage, typename Orientation, std::size_t Order>
struct traits {
typedef Storage storage_category;
typedef Orientation orientation_category;
static constexpr std::size_t tensor_order = Order;
}
0b. Make sure the traits model is easily extendable
1a. Dense tensor_view class and appropriate template specialization for
matrix and vector classes that people are more accommodated with. Do not
forget static containers!
1a. Sparse tensor_view and template specialization for matrix and vector
classes if applicable. Otherwise implement only specialized sparse
containers.
1b. tensor, matrix, vector classes (own data instead of views, probably
wrap around views)
2a. Development of new expression template mechanism and introduction of
computational kernel concept alongside with threaded implementation.
2b. Range and/or Summation convention/Einstein notation mechanism
3. Everything else.
Ideas/thoughts are welcomed.
-Nasos
>
> 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]
> <mailto: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: athanasios.iliopoulos.ctr.gr_at_[hidden]