|
|
Ublas : |
Subject: Re: [ublas] Status of development /Benchmarks
From: Athanasios Iliopoulos (athanasios.iliopoulos.ctr.gr_at_[hidden])
Date: 2013-12-09 09:26:58
On 12/09/2013 05:18 AM, sguazt wrote:
>
>
>
> On Mon, Dec 9, 2013 at 10:13 AM, Rutger ter Borg <rutger_at_[hidden]
> <mailto:rutger_at_[hidden]>> wrote:
>
>
> Hey David,
>
> the whole problem of most numerical packages, IMHO, is that
> everything is tied together. I would encourage a very loosely
> coupled system. I.e., a system that maybe even would be able to
> switch storage layout, algorithms, etc., at run-time, maybe
> following some simple numerical tests. Of course, only if this
> would be enabled at compile-time.
>
> Data storage and manipulation should be fully loosely coupled,
> from low abstraction to high abstraction:
>
> * the storage of data. This is about memory-efficiency, and hence,
> speed of computation. Storage engines might be linear, sparse, etc..
> * functional shape of the data. Dense, triangular, etc.
> * numerical properties of the data. Positive definite, etc.
> * loading and saving the data. Why not support a whole bunch of
> data-formats
> * unified matrix/vector view on the data
> * procedural manipulation of the data, shallow views on the data,
> views on views, etc.
>
> Algorithms should be loosely coupled, too, from low abstraction to
> high abstraction:
>
> * execution / memory models (synchronous, asynchronous, single
> core, multi-core, shared memory, distributed memory, GPU memory)
> * computational kernels (own C++ CPU-optimized implementations,
> openblas, atlas, gotoblas2, lapack, mumps, opencl, cuda, fft, etc)
> * expression trees, syntax of expression trees (Boost.Proto stuff)
> * optimal assignment of computational kernels to expression trees
> (maybe partly at runtime!)
> * being able to extend the expression tree machinery (e.g., with
> hooks) with own algorithms
>
>
> +1 for a library with loosely-coupled feature, even if this means a
> completely rewriting of uBLAS
>
> For the integration of computational kernels, why don't we use the
> boost-numeric_bindings lib?
The bindings are good for certain items that are hard to implement
(especially for example for linear system solvers), but for other items
I think it would be better if we had full implementations into uBlas.
> Also, I'd like to have more MATLAB-like functionalities (I've
> implemented some of them in boost-ublasx, but they relies on
> boost-numeric_bindings and LAPACK functions)
>
> Best,
>
> -- Marco
>
>
> Maybe a new library name would be appropriate?
>
> Cheers,
>
> Rutger
>
>
>
>
>
> On 2013-12-07 11:38, 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.
>
> 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
>
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden] <mailto:ublas_at_[hidden]>
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: marco.guazzone_at_[hidden] <mailto:marco.guazzone_at_[hidden]>
>
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]
-- Dr Athanasios Iliopoulos Research Assistant Professor George Mason University Resident at Computational Multiphysics Systems Lab. Code 6394 Center of Computational Material Science Naval Research Laboratory 4555 Overlook Ave. SW, Washington DC 20375 Tel : +1 202 767 2165 e-mail: athanasios.iliopoulos.ctr.gr_at_[hidden] URL: https://www.nrl.navy.mil/mstd/ccms/cmsl/