|
|
Ublas : |
Subject: Re: [ublas] GSOC 2013
From: Joaquim Duran (jduran.gm_at_[hidden])
Date: 2013-04-09 04:02:07
>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_at_[hidden]>
> 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_at_[hidden]>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 listublas_at_[hidden]http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> ublas_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: david.bellot_at_[hidden]
>>
>
>
>
> _______________________________________________
> ublas mailing listublas_at_[hidden]http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: jduran.gm_at_[hidden]
>