Description
Currently, all strategies for CSR are tailored for CUDA, which is fine for the most part.
However, also the names are CUDA specific (see Csr::cusparse), which should be changed in my opinion since we want to support multiple platforms. I would prefer to go with a more neutral name like Csr::sparse_library in that case (maybe there is even an OpenMP sparse library we could use for that).
Also, automatical only works on CUDA devices and even requires a CudaExecutor to work. I would prefer a solution where it is possible to also adapt to certain OpenMP properties (which we should have as soon as we have a more sophisticated SpMV there).
Additionally, I am not sure why we use an std::shared_ptr for these strategies. Currently, we always have to call std::make_shared to generate a strategy, which is both not intuitive and not necessary since there is not much stored inside a strategy object (at most an std::string and an int64_t). I think copying the object would be faster than allocating memory on the heap, although it should not really matter much (the more important part for me is the intuitiveness).
We could also encapsulate the strategies in a class named strategy, so it is clear that Csr::spmv_strategy::automatical is an SpMV strategy.
In summary, I think the following changes should be introduced:
- Change the names of the strategies to more neutral ones, e.g.
cusparse->sparse_library - Make
automaticalto actually be automatical and dependent on the executor (CUDA vs. OpenMP vs. Reference) without requiring a CudaExecutor - Change the type of the strategy from
std::shared_ptrto just a plain object since the most one of these objects contain is anint64_tand anstd::string - put all strategy classes in a separate class
spmv_strategy(or similar), so you call it withCsr::spmv_strategy::automatical, which is more descriptive
Additionally, some functionality/performance changes can also be incorporated into the strategies:
- Split the generate/prepare step required for some strategies (cusparse. hipsparse) and move them if possible to
make_srowto keep data persistent over manyapplycalls optimizing the apply calls. See discussion here.