Open learning-chip opened 2 years ago
SuiteSparseGraphBLAS.gbset(:nthreads, <NUMTHREADS>)
. You can get the current number using SuiteSparseGraphBLAS.gbget(:nthreads)
.
This interface needs to be both improved and better documented, sorry about that. This is what it currently does: gbset(:nthreads, Sys.CPU_THREADS ÷ 2)
on startup. I will likely change that at some point to use one of the environment variables above.
Note that it probably isn't going to use 56 threads on a problem of that size (or if it does it's not going to be scaling well). For most of the internal kernels you can observe what's happening with gbset(:burble, true)
. That will make SuiteSparse:GraphBLAS print out its internal diagnostic information, which includes the number of threads used.
SuiteSparseGraphBLAS.gbset(:nthreads,
)
This works well, thanks!
I'm going to leave this open until I find a better interface
In a similar vein, do you know if multi-threading works on Apple ARM chips? Changing the number of threads with gbset
has an impact on the number of threads reported by burble
but it does not have an impact on the runtime or the CPU usage.
The benchmark section shows faster execution with more threads. However, I cannot reproduce such parallel scaling.
The benchmark script:
Run with:
Then, by changing any of the
*_NUM_THREADS
variables, the execution time always stays the same (~180ms on my 112-core machine). It is 7x faster than the built-in sparse matmul (~1.2s). However I don't really know how many threads it is using, and doesn't seem to be able to change it.