Hi Lumin, Le mercredi 15 mai 2019 à 08:39 -0700, Mo Zhou a écrit : > (1) building problem about OpenBLAS's liblapack64.so > ----------------------------------------------------- > > Sébastien provided some possible solutions: > > 1. build a 64-bit indexing variant of src:lapack > 2. provide a liblapack64-pic (Sébastien prefer this) First, note that solution 1 is a superset of solution 2 (i.e. we would also provide liblapack64-pic in solution 1). Actually solution 1 is my preferred one. But since I do not have the time to work on it in the immediate future, and since you’ve said you were not interested in investing time in non- optimized implementations, I would be ok if you were implementing solution 2 as an intermediate step. Then I could implement 1 later. > Yes, the solution *2 poses very little workload because > we just need to rebuild lapack with fortran flag "-i8". > > However, I'm thinking about the 3-rd solution: > > 3. disentangle src:lapack and src:openblas and just > use src:openblas's embedded copy of src:lapack. > (currently that embedded copy is removed from debian > source) I don’t think this is an acceptable solution. I deliberately stripped the embedded copy of src:lapack in order to follow best practices. See Debian Policy §4.13 and https://wiki.debian.org/EmbeddedCodeCopies > (2) confirming details for our standard of BLAS/LAPACK virtual packages > ----------------------------------------------------------------------- > 1. BLAS/CBLAS packages looks relatively tidy, except Atlas > which splitted CBLAS into a separate libcblas.so . This is not true, as you can easily verify by running: nm -D /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 | grep cblas_ > That's a pitfall and numpy had ever fell into it: #913567 The numpy issue is unrelated. > Debian's Atlas is terribly slow due to ISA baseline.[2] Note that ATLAS is meant to be recompiled locally in order to get best performance, as explained in the extended description of the package. But it’s true that it’s slower than OpenBLAS and BLIS. > Should we squash Atlas's libcblas.so back into it's > libblas.so ? [3] Like all other alternative libraries did. As said above, this is already done. > 2. LAPACK and LAPACKE are well-seperated into different > shared libraries. Sometimes LAPACKE is simply not > built. LAPACK has been registered in the alternatives > system: "liblapack.so", "liblapack.so.3". > > Can we confirm that it's fine to provide only LAPACK > via liblapack.so and don't register LAPACKE in the > alternatives system? Yes I think it’s fine. LAPACKE is only a thin C wrapper above LAPACK, and there is only one implementation of that wrapper. And liblapacke.so is dynamically linked against liblapack.so, so it will pick whatever LAPACK implementation is currently selected in the alternatives system. Thanks for your work on BLAS/LAPACK, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part