All types of Eigen::SparseMatrix are now supported. For that, the implementation relies completely on the Eigen matrix product to compute the intersection. The trick is to flag the non-zero values with its index position in the array. The matrix product will implicitly keep track of all the operations thanks to the newly introduced scalar types.
Because of the new method, SparseMatrixStorageOrder is no longer useful. It can be removed later
Unit tests are extensive. They test all possible configuration of storage of LHS, RHS and Result. They are required because a condition on the storage type is required to swap the indices after the matrix product.
The best configuration storage for the fast matrix product seems to be ColColCol
The fast matrix product is always faster than the regular product, except for a matrix of size 1000 and sparsity of 15%. This probably indicates that the method is adapted for very sparse matrices
The parallel fast matrix product algorithm is always faster than the sequential algorithm, except for very small matrices where the overhead of parallelism is not negligible. However, the speed up is not linear with the number of cores and can be disappointing.
The parallel fast matrix product is always faster than the regular product even for the matrix of size 1000 and sparsity of 15%, but not for very small matrices (overhead).
SparseMatrixStorageOrder
is no longer useful. It can be removed laterAnalysis of the results of the benchmarks:
By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).
Reviewers will merge this pull-request only if