wrtobin / las

Zero-overhead interfaces to Linear Algebraic data structures and Solvers
1 stars 1 forks source link

Template non-zero overhead api #67

Closed jacobmerson closed 5 years ago

jacobmerson commented 5 years ago

@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 of ifdefs for each backend which we might potentially use.

The potential issues I see here is that

  1. it might require changes to the capi
  2. since it "drastically" changes the las api it might cause you issues in the fusion project which uses las
wrtobin commented 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.

jacobmerson commented 5 years ago

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?

wrtobin commented 5 years ago

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.

wrtobin commented 5 years ago

Actually looking it up I don't think we even need to explicitly specialize MatVecMult<petsc>

jacobmerson commented 5 years ago

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);
}