|
|
Glas :[glas] backend selection policies |
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2006-02-02 18:16:09
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