|
|
Ublas : |
Subject: Re: [ublas] Status of development /Benchmarks
From: sguazt (marco.guazzone_at_[hidden])
Date: 2013-12-09 05:18:58
On Mon, Dec 9, 2013 at 10:13 AM, Rutger ter Borg <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?
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]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: marco.guazzone_at_[hidden]
>