SparseBase New Formats Issue

sparsebase_new_formats_issue.md

SparseBase's current (as of version 0.1.2) format system has several weaknesses that we would like to address in the upcomming releases. Here I will be describing these weaknesses. We are already working on new designs and we are also open to suggestions.

Templates

Currently, most classes in the library have three templated types (IDType, NNZType, ValType). These allow the users to set the various underlying arrays of the sparse format to different types. For example all 3 arrays of a CSR could be different types allowing flexible memory and precision management. Since SparseBase's main goal is to accommodate the user's needs, this flexibility is an important feature.

However this system introduces some problems:

1. We are stuck with these 3 types which might not scale well to a tensor. Since tensor implementations could have any number of arrays, there would be less control on the types of tensor arrays.
2. Templates take a long time to compile which will only get worse as the library increases in complexity.
3. Some sparse formats, e.g., HiCOO leverage arrays of more than three different types. (This could be hardcoded for specific formats but a general solution is preferred).

We are not trying to remove all templates from the library, but we are trying to reduce our reliance on them.

Dynamic Casts

Currently, a lot of the functions that return SparseFormat objects (like converters and transformers) return a SparseFormat pointer. Then the user has to use dynamic_cast to get a pointer to a CSR or COO. There are 2 problems with this system:

1. Ideally this casting should be handled by SparseBase itself with minimal responsibility on the user.
2. Dynamic cast is relatively slow. Since this is a HPC library, this is not acceptable. Ideally we should be using static casts if possible.

Excessive Copying

Consider the following code snippet where the user converted a COO object to a CSR object using our converter system.

COO<int,int,int>* coo = new COO<int,int,int>(6, 6, 6, row, col, vals);
auto converter = new SparseConverter<int,int,int>();
auto csr = converter->Convert(coo,kCSRFormat);
auto csr2 = dynamic_cast<CSR<int,int,int>*>(csr);

col and vals arrays of COO and CSR are actually identical. But as of the current (0.1.2) release, the converter will copy these arrays while constructing the CSR. The advantage of this is that both CSR and COO objects are usable after the conversion. But of course this is inefficient which is unaccaptable since this is a HPC library. We should instead favor a move based conversion and allow users to explicitly copy the objects if they want to keep them.

Summarizes the problems with the current design nicely. For the last problem, I'm trying to tackle this issue with the ownership model. I'll create an issue with it soon.

you can also add this to the problems:
3. Some sparse formats, e.g., HiCOO leverage arrays of more than three different types. (This could be hardcoded for specific formats but a general solution is preferred).