Canonicalize source file name in tests for BLAS threading.#1009
Conversation
These tests are run repeatedly for different libraries. Canonicalize the path to the source files of the tests to allow early deduplication. This avoids issues with some generators (e.g., Ninja). Fixes DrTimothyAldenDavis#1008.
|
Thanks for the update -- I'll give it a try shortly. It can't be done as a runtime check, unfortunately. The Apr 2024 version of OpenBLAS adds a new function, openblas_set_num_threads_local, that appears in 0.3.27 but not doesn't appear in earlier versions. It also doesn't appear in any other BLAS library. The Intel MKL library has an mkl_set_num_threads_local, and has had it for a long time. This OpenBLAS function does the same thing, but for the OpenBLAS library. We need this functionality in ParU, for best performance. if the functions are not available, then ParU has to use a different method for its own parallelism. I don't think it would be possible to check if these functions exist at run time. The check would have to be done at link time at the latest, perhaps dynamically, but I don't know how to do that in a portable way. So the only time I can do this check is at compile time of ParU, to determine if these functions are available. It's an unfortunate situation. Both MKL and OpenBLAS are making up for a fundamental flaw in the BLAS library standard, by allowing the caller to control the # of threads used by any given call to the BLAS, on a per-user-thread basis. But they've done so in different ways, with different function names. So a compile time test is the only think I can do. |
DrTimothyAldenDavis
merged commit 32083d5
into
DrTimothyAldenDavis:dev2
|
The update works on my desktop ("hyper") but fails on my laptop ("slash"). The slash output: The "hyper" output: |
|
Should line this be "${ABS_SOURCE_PATH}"? |
Oops. That should be it indeed. |
Unfortunately, that isn't possible cross-platform. But it should be possible to use On Windows, that's a bit more complicated. But you could use something like the following: (That assumes that no more than 1024 libraries are loaded at the same time...) In both cases, |
No worries -- I can fix it. My tests on the "hyper" desktop passed by mistake; I forgot the "git pull" to bring in this latest update. With the "git pull" it fails the same way as my laptop, and with the fix to this line, it works. I was surprised it passed on my desktop but failed on my laptop since I have the MKL on both systems. But it was just a mistake; they both failed. I made the change just now and it works on my desktop with MKL now. (see 0b3ea61 ). I will release a SuiteSparse 7.12.1 with this update, so it can work in flatpak (issue #1008). |
2 participants
These tests are run repeatedly for different libraries. Canonicalize the path to the source files of the tests to allow early deduplication. This avoids issues with some generators (e.g., Ninja).
Fixes #1008.
In general, it might be a good idea to convert these to runtime checks instead of configure checks. Otherwise, it might lead to strange results if the BLAS implementation changes after the libraries have been built (e.g., with Debian's alternatives mechanism).