Dear Giulio, Le mardi 30 mai 2023 à 11:32 -0400, Giulio Genovese a écrit : > There are two issues related to CHOLMOD. > > The first issue is that the libsuitesparse-dev package includes the > headers in the /usr/include/suitesparse/ rather than the > /usr/include/ directory which is not what SutieSparse does by default > and it is not what other package managers do (e.g. Homebrew and > Conda), creating an heterogeneous set of environments that > complicates the situation for developers. > > Since SuiteSparse has recently consolidated many of its header files > with the latest release, I do wonder whether it would be a good time > to revisit the decision to keep the headers in > /usr/include/suitesparse/ as this could create a uniform environment > across distributions. If having all headers in /usr/include/ is still > considered too much, could a soft link to > /usr/include/suitesparse/cholmod.h be present in /usr/include/? This > would allow code calling this header with the command: > #include "cholmod.h" > To work without issues across different environments. As the suitesparse package maintainer, I understand your point that such a move would provide more homogeneity across distributions, and would be more in line with upstream’s practice. On the other hand, this move is not straightforward (because that implies adapting the many Debian packages that depend on suitesparse). More importantly, having for e.g. /usr/include/amd.h would be highly confusing to most users, because the average user would expect that amd.h is related to AMD the processor brand. Even upstream acknowledges this problem, and recognizes that putting everything under /usr/include/suitesparse/ from the beginning would have been better.¹ Since Debian has already made the transition long ago to that better location, I’m rather inclined to keep it as it is. Note that most upstream packages are anyways already used to dealing with the two different locations. Also note that creating a symlink for just one header (cholmod.h), as you suggest as an alternative, seems weird and not in line with usual Debian practices. > The other issue is that CHOLMOD performance is significantly degraded > by libopenblas0-pthread, one of the packages that provides > libblas.so.3. As CHOLMOD is based on OpenMP, using a multi-threaded > version of BLAS causes significant cache issues when running multi- > threaded functions. I have observed CHOLMOD running twice as fast > when using libopenblas0-openmp instead of libopenblas0-pthread. > Although it would not solve all configurations, could the libcholmod4 > debian package recommend the installation of libopenblas0-openmp? > This would not guarantee that users would use the OpenMP version of > OpenBLAS when running CHOLMOD for users that have already a non- > OpenMP version installed, but it would at least default to this > version for users that don't have OpenBLAS installed to begin with. > > There might be other workarounds that I have not thought of so I am > open to alternative suggestions. Thanks for raising this issue, I was not aware of it. Interaction between pthread and OpenMP at different levels of the dependency tree has always been a delicate issue (see for example #737675 and #739331). Your suggestion to add a Recommends over libopenblas0-openmp in libcholmod4 could be a solution, but it may create problems in some applications given our historical experience (but maybe the situation has improved, I don’t know). Also it won’t work in all cases, because the OpenBLAS flavours are handled by the alternatives system, and the pthread flavour currently has a higher priority than the OpenMP one (so that if both are installed, the pthread flavour takes precedence unless the user explicitly says otherwise). I would be interested in hearing the opinion from others on this list who have more experience with this issue. Best wishes, ¹ https://github.com/DrTimothyAldenDavis/SuiteSparse/issues/177#issuecomment-1374828162 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part