Closed jacobmerson closed 5 years ago
Either this or something like this was on the roadmap for las, so I'm all for it. Just be aware that a backend might have multiple implementations of a particular operation if e.g. it also supports multiple matrix memory layouts, etc, so there also needs to be a mechanism to retrieve alternate implementations of the same operation using the same backend.
Do you have an example of what a use case for this would look like? Is it something where modifying the exec
call for the class is sufficient, or adding in another call e.g. exec_memlayout1()
, exec_memlayout2
?
It should be the case that the class APIs are identical. We could do multiple subclasses of the template base class specialized on the backend, so:
template <>
class PetscMatVecMultA : public MatVecMult<petsc>
{ };
template < >
class PetscMatVecMultB : public MatVecMult<petsc>
{ };
Where we explicitly specialized MatVecMult<petsc>
might work, though we need an API mechanism to retrieve different subclasses as the superclass MatVecMult<petsc>
using some arbitrary (int
, enum
, etc) identifier.
Actually looking it up I don't think we even need to explicitly specialize MatVecMult<petsc>
It looks like the method that I am using here is forward compatible. E.g. if we want to add the capability for extra backends at some point we can use a default template parameter e.g.
#include <iostream>
template <typename T, unsigned N=2>
void print(T instr)
{
std::cout<<instr<<" "<<N<<std::endl;
}
int main(int argc, char ** argv) {
std::string s = "test string";
print<std::string, 5>(s);
print<std::string, 5>(s);
}
@wrtobin I want your input on the following.
After working with the las api for a bit I would like to make the non-zero overhead api use template specializations, rather than the current method where you have e.g.
getSparseMatVecMult()
,getPetscMatVecMult()
, etc.I would like this to be
MatVecMult<backend> mvm();
This way we can use the compile time definition of the backend to choose the correct class, rather than needing to use a bunch ofifdefs
for each backend which we might potentially use.The potential issues I see here is that