Open DimaLPorNLP opened 1 week ago
my_demo isn't meant to be used in practice to actually solve any systems -- it's purpose is to be a minimalist demo on how to compile and link a user's application against some or all of the SuiteSparse packages.
GraphBLAS isn't a solver. It's a package that enables high-performance graph algorithms. It has many built-in semirings in addition to the conventional plus-times, which is why it is so large. However, you can compile it in a 'GRAPHBLAS_COMPACT' mode which disables the built-in semirings. GraphBLAS will still be fast, once it compiles the semirings you use at run time (via its built-in JIT).
Try setting the GraphBLAS cmake option of GRAPHBLAS_COMPACT, with
cd build && cmake -DGRAPHBLAS_COMPACT=1 .. && cmake --build . --config Release -j20
either inside GraphBLAS, or in the top level SuiteSparse folder. You can also just do "make compact" inside GraphBLAS. This reduces the libgraphblas.so to be about 9MB.
Current status The my_demo example once it gets compiled it runs for a small hard-coded matrix. For being compiled it requires that all algorithms in SuiteSparse have been built. GraphBlas however, requires about 500MB of disk space and it takes significant time to build in contrast to the rest sparse linear solver algorithms most of the people possibly need which occupy approximately 30MB.
Feature Wouldn't it be better that the matrix is passed as a command line argument in .csr or .triplet format so that the users can test the several algorithms with their own matrices?
Additionally The algorithm to be tested could also be a 2nd command line argument (if specified) and furthermore, #ifdef #endif preprocessor directives could be automatically enabled in configure time relevant to the projects that have been "ENABLED". This way my_demo always compiles independently of how many algorithms are enable in cmake.