Re: Status of development /Benchmarks

Rutger,
can you provide a short interface example of your most important points. 
I am interested for example in things like: how ti pick the execution 
model, for example for expression template algorithms?

-Nasos

On 12/09/2013 04:13 AM, Rutger ter Borg 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
>
> 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
> [email protected]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]