>Since mdsd:array is a generic multi-dimensional container it is not bound to algebraic operations. I expect that with proper aligned memory allocation and SSE aglorithms (It is easy to add a custom storage container that supports that) it will be as fast as MKL, GotoBLAS, Eigen or armadillo. I believe that within that context, a GSOC project will need to include both the matrix container and the SSE algorithms tasks, or even AVX. (http://en.wikipedia.org/wiki/Advanced_Vector_Extensions)

Sorry to answer the mesage so late, but, IMO its a good idea no bound the oeprations to the container, so many implementations of the operations could be implemented, and expand the library, event linking with other libraries. To name few possible implementations are:

- Scalar: implement them as currently. Vectorization is done by compiler.
- boost::simd (http://nt2.metascale.fr/doc/html/the_boost_simd_library.html): access to SSE2, AVR and other SIMD extensions.
- OpenCL: use GPU's or generic CPU's for calculations.
- boost::mpi: for use in clustering environments.

Other implementationg calling to functions of other libraries, like blas, lapack or similar libraries could be also be implemented.

Joaquim Duran




2013/3/23 Nasos Iliopoulos <nasos_i@hotmail.com>
David,
Since mdsd:array is a generic multi-dimensional container it is not bound to algebraic operations. I expect that with proper aligned memory allocation and SSE aglorithms (It is easy to add a custom storage container that supports that) it will be as fast as MKL, GotoBLAS, Eigen or armadillo. I believe that within that context, a GSOC project will need to include both the matrix container and the SSE algorithms tasks, or even AVX. (http://en.wikipedia.org/wiki/Advanced_Vector_Extensions)

In any case I would like to emphasize that although I would like to see uBlas to compete at the vector-operation level, I think it should not lock itself out from high performance computing interfaces.

A nice project that I have in mind for the latter is  the tpetra package of trillinos: http://trilinos.sandia.gov/packages/docs/r11.0/packages/tpetra/doc/html/index.html.  Altough Sandia is doing some impressive job putting together  modern C++ computational packages I feel that a more refined version can provide a more consisent C++ interface.

Best,
Nasos




On 03/23/2013 10:44 AM, David Bellot wrote:
Wow it looks indeed very interesting. Yes, I know what you mean by "rare free time". Same thing here :-)
Let me have a more thorough look at it and why not start using it too.
Have you compared it to what is done with Eigen and Armadillo. It seems these 2 libraries are quite popular these days.

Best,
David

On Sat, Mar 23, 2013 at 1:39 PM, Nasos Iliopoulos <nasos_i@hotmail.com> wrote:
David,
I have been working on a generic stato-dynamic multi-dimensional array that can enable something like what you propose. It uses C++11 functionality (variadic templates and functions mainly). Please take a look at: https://github.com/nasosi/mdsdarray and https://github.com/nasosi/mdsdarray/wiki/Interface-examples.  The developement is slow-paced because I am working on it at the rare free time I have on weekends.
I am currently thinking of how to implement an appropriate iterator that would be SIMD friendly. In that context I am considering something across the lines of the interface of OpenCL and CUDA. This would work nicely with the C+11 new for loops as well.

If you think your proposal can build on top or even contribute to mdsdarray,  I can provide a version under a Boost or  MIT license.

Best,
-Nasos



On 03/23/2013 08:47 AM, David Bellot wrote:
Hi guys,

I proposed a Google Summer of Code project for uBLAS.
It's based on the wish list that has been done some time ago a long time ago.

The main idea is to refactor vector into matrix to have only one internal and external representation, one set of algorithm. As a convenience, the class vector<> will still exist and will, for example, be by default a row-vector (like a simple C-array would be). Or a column-vector if we prefer but I think matlab is row-oriented by default (and I hate R which is column oriented, even if I use it every single day at work !!! :-D :-D ah ah ah ah ! Let the flame war begin).

OK, the idea behind this is to have a clean framework to enable optimization based on SSE, Neon, multi-core, ... you name it.
I'm sure the student who will work on that will take inspiration from boost::bindings, Eigen, Armadillo, etc...
The project is very open, so suggestions are most welcome.

Best,
David



_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil


_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com



_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil


_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: jduran.gm@gmail.com