Re: Towards lapack / lapack64 packaging
Hi Sébastien,
On 2019-05-15 16:23, Sébastien Villemot wrote:
>> 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.
Let's implement solution 1. That enables us to provide
a unified dependency template for libblas64.so and
liblapack64.so* . The current dependency template for
src:blis' libblas64.so.3 is:
libblas64.so.3 libblis64-2 | libblas64.so.3 #MINVER#
which is not aligned with 32-bit indexing version,
due to the absence of a standard one.
Let's first comment out the lapack64 bits for openblas
and get blas64 updates uploaded. Then I'll look into
updating the netlib for blas64 and lapack64. This is
technically the best choice, yet requires some more
time to be done.
>> 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
Well, I understand that but human sometimes thinks about
slacking off and doing something ungraceful.
>> (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_
Oops, I overlooked that.
>> That's a pitfall and numpy had ever fell into it: #913567
>
> The numpy issue is unrelated.
My point is that the existence of atlas' libcblas.so is
sometimes misguiding: when a package asks for a cblas
library, the maintainer will first
apt search libcblas
and they will find nothing. Then they will
apt-file search libcblas
and find atlas and set it as the dependency.
Maintainers without enough background on BLAS / LAPACK
are likely to be misguided. And they don't necessarily
know that Debian's default Atlas package (without
tuning) is really slow.
>> 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.
An untuned Atlas library (apt install libatlas3-base),
running in multi-threaded mode is even slower than BLIS
that runs in single-threaded mode.
To users who don't have enough background or who don't
read the doc, this is a performance pitfall.
>> 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.
Indeed. There is nothing to fix.
>> 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.
ACK. Thanks for confirming, that saved me much time for
reading the code.
> Thanks for your work on BLAS/LAPACK,
Reply to: