Re: [glas] using blas kernels
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-09-09 09:23:11
On Friday 09 September 2005 15:58, Toon Knapen wrote:
> Karl Meerbergen wrote:
> > Something we have discussed in the past is the use of blas kernels in
> > algorithms.
> > There are several ways of using those:
> > - dedicates function names: e.g. norm_1_blas(v)
> > - hard code the collection whether blas should be used or not in
> > norm_1(v).
> I think we should exploit multiple modus operandi:
> A first mode is to use the algorithm as implemented in glas itself. I
> also suggest that this is the default mode.
> A second mode is that glas tries to dispatch as much as possible to glas
> (of course only if a corresponding blas call exists).
you mean as much as possible to blas (not glas)?!
> A third mode might be that glas decides if it will dispatch to glas or
> use its own implementation. I don't think we will support this system
> soon though because glas would need to be sure which implementation will
> be best suited for all different cases.
> Of course if users want to force that blas will be used, they should be
> able to just call a binding for the blas function that accepts the glas
> containers (cfr. the blas-bindings in the boost-sandbox).
I think it would be better to organise this using an adaptor to the collection
or have collections that use blas calls all the time. It allows the user to
use the same function names for different implementations. The blas
implementation uses the boost-sandbox bindings. It prevents the glas user to
know the glas function names and the boost-sandbox blas names for
mathematically the same operation.
Similar strategies can be used for blocked algorithms etc.
We could add a template argt to e.g. glas::vector that tells which
implementation should be used. Adaptors would then allow to change the
glas::vector<double,...,blas> using blas calls
glas::vector<double,...,blocked_glas> using blocked algorithms, etc.
using blas(v) or blocked(v) modifies the default.
I am not sure this is clear.