Thanks for the sr. I understand the rationale behind the change, but I wonder why you choose '4' as the CPU count. This seems to be on the lower side for modern desktops/laptops, not to mention more powerful workstations.
Perhaps we could set the number of cores at post-install with a script that first determines the number of cores on the machine the package is being installed to?
https://store.steampowered.com/hwsurvey/cpus/ shows that 65% of machines have 6 or fewer cores. And the current openblas-common-devel comes with a MAX_THREADS=4 as well, so it is no change to what we had before.
The maximum number of threads users will be able to use is determined at build
time by the NUM_THREADS build option. It defaults to 24, and there's a wide
range of values that are reasonable to use (up to 256). 64 is a typical choice
here; there is a memory footprint penalty that is linear in NUM_THREADS.
Please see Makefile.rule for more details.
NUM_THREADS is already fixed to 64 (or 256 for HPC builds).
Our previous openblas.pc file did have a NUM_THREADS=4 because the build-worker happened to have this many cores.
Even though we built with NUM_THREADS=64
@Dmitry_R, @StefanBruens, @TheBlackCat, @adrianSuSE, @anag, @badshah400, @dstoecker, @eeich, @kwk, @lrupp, @mslacken, @openfoam, @psmt: review reminder
Thanks for the sr. I understand the rationale behind the change, but I wonder why you choose '4' as the CPU count. This seems to be on the lower side for modern desktops/laptops, not to mention more powerful workstations.
Perhaps we could set the number of cores at post-install with a script that first determines the number of cores on the machine the package is being installed to?
https://store.steampowered.com/hwsurvey/cpus/ shows that 65% of machines have 6 or fewer cores. And the current
openblas-common-develcomes with aMAX_THREADS=4as well, so it is no change to what we had before.I see. I still would like to implement setting this with a post scriptlet (when I have time). Do you think that would be a wise thing to do?
Anyway, for now, this looks good. Many thanks.
%post scripts are problematic for transactional updates and also not nice for building reproducible images.
OK, thanks for the discussion. Let us just leave this at '4' then.
Note this is "physical cores", for most machines you have to double that.
Also, MAX_THREADS is a compile time option to limit the number of CPUs supported by the library, for the runtime thread limit, see:
https://github.com/OpenMathLib/OpenBLAS#setting-the-number-of-threads-using-environment-variables
openblas-common-devel does not contain any value at all, it just provides a symlink managed via
alternatives.This change is actually incorrect: https://github.com/OpenMathLib/OpenBLAS/blob/96f8bb1eb9bb4f89635293c382a4db2bcb5fbc03/docs/distributing.md?plain=1#L228
NUM_THREADS is already fixed to 64 (or 256 for HPC builds).
Our previous
openblas.pcfile did have aNUM_THREADS=4because the build-worker happened to have this many cores. Even though we built withNUM_THREADS=64Yes, it was not propagating through make install, see Stefan's currently open SR.
Alright, https://build.opensuse.org/request/show/1120798 makes sense.