backend selection policies

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

backend selection policies

Toon Knapen
Hi all,

I just checked in support for backend-selection policies (tested on
mult_scalar_assign functor). Such policies allow the user to say to
dispatch a specific call to blas (and return an error if the call can
not be handled by blas),  or to try to dispatch to blas and otherwise
dispatch to glas etc.

For instance, take following code fragment:
<code>
glas::dense_vector< std::complex<double> > v(10) ;
std::complex< double > scalar(1,1) ;
glas::mult_assign_scalar< glas::backend_blas_glas >( v, scalar ) ;
</code>

In line 3, the 'mult_assign_scalar' function is called with the
backend-selection-policy as a template argument (in this case
'glas::backend_blas_glas'). This policy dictates that first the
dispatching mechanism should first evaluate if the call can be
dispatched to a blas equivalent (at compile-time using boost::mpl
functionality etc). If no blas equivalent is available, the policy says
to fallback to the generic glas implementation. Thus line 3 will
actually call 'zscal' in this case.

Suppose however that the vector 'v' is a vector of integers (instead of
double-complex), no BLAS equivalent exists. In that case the
'glas::backend_blas_glas' policy will detect that the call is not
directly supported by blas and will then dispatch to the generic glas
implementation.

I guess support for such policies allow the requisted flexibility
regarding the integration/selection of backends. If not, let me know.

toon
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas
Reply | Threaded
Open this post in threaded view
|

Re: backend selection policies

Karl Meerbergen
Toon Knapen wrote:

>Hi all,
>
>I just checked in support for backend-selection policies (tested on
>mult_scalar_assign functor). Such policies allow the user to say to
>dispatch a specific call to blas (and return an error if the call can
>not be handled by blas),  or to try to dispatch to blas and otherwise
>dispatch to glas etc.
>
>For instance, take following code fragment:
><code>
>glas::dense_vector< std::complex<double> > v(10) ;
>std::complex< double > scalar(1,1) ;
>glas::mult_assign_scalar< glas::backend_blas_glas >( v, scalar ) ;
></code>
>

I would also allow adaptors (or policy selectors) so that we can use the
syntax
  backend_blas_glas( v ) *= scalar ;
where
  v *= scalar ;
uses the default backend.

The left hand side then decides that the expression on the right-hand
side is evaluated with this backend.

A similar mechanism can be used for assignment policies.

The advantage is that the choice of backend can be used with operators
as well.

Other syntaxes have been proposed: v[backed_blas_glas] *= scalar
but I am not very keen on using the operator[] for this purpose.


Karl


>
>In line 3, the 'mult_assign_scalar' function is called with the
>backend-selection-policy as a template argument (in this case
>'glas::backend_blas_glas'). This policy dictates that first the
>dispatching mechanism should first evaluate if the call can be
>dispatched to a blas equivalent (at compile-time using boost::mpl
>functionality etc). If no blas equivalent is available, the policy says
>to fallback to the generic glas implementation. Thus line 3 will
>actually call 'zscal' in this case.
>
>Suppose however that the vector 'v' is a vector of integers (instead of
>double-complex), no BLAS equivalent exists. In that case the
>'glas::backend_blas_glas' policy will detect that the call is not
>directly supported by blas and will then dispatch to the generic glas
>implementation.
>
>I guess support for such policies allow the requisted flexibility
>regarding the integration/selection of backends. If not, let me know.
>
>toon
>_______________________________________________
>glas mailing list
>[hidden email]
>http://lists.boost.org/mailman/listinfo.cgi/glas
>
>  
>


--
==============================================
Look at our unique training program and
Register on-line at http://www.fft.be/?id=35
----------------------------------------------

Karl Meerbergen

Free Field Technologies

NEW ADDRESS FROM FEBRUARY 1st ONWARD:

Axis Park Louvain-la-Neuve
rue Emile Francqui, 1
B-1435 Mont-Saint Guibert - BELGIUM

Company Phone:  +32 10 45 12 26
Company Fax:    +32 10 45 46 26
Mobile Phone:   +32 474 26 66 59
Home Phone:     +32 2 306 38 10
mailto:[hidden email]
http://www.fft.be
============================================



_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas