[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libsuitesparse-dev and libcholmod4



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


Reply to: