Re: Status of development /Benchmarks

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

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
>
>