Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK
On Mon, 2018-10-22 at 15:07 +0000, Mo Zhou wrote:
> Hi Wookey and Bastian,
>
> On Sun, Oct 21, 2018 at 06:51:16PM +0100, Wookey wrote:
> > On 2018-10-21 17:16 +0200, Bastian Blank wrote:
> > > Hi
> > >
> > > On Sun, Oct 21, 2018 at 09:51:15AM +0000, Mo Zhou wrote:
> > > > about naming convention of SONAME and package name.
> > > >
> > > > As discussed in [1][2][3], Debian will need a set of ILP64[4] interface
> > > > to BLAS/LAPACK in the future.
> > >
> > > Could you please describe what you mean? All 64-bit Debian
> > > architectures are LP64. So building a single binary using ILP64 will
> > > even break the ABI for glibc and it will most likely not run very far.
> > > (A file descriptor is defined as "int", so even the most basic file
> > > calls will be incompatible.)
>
> I missed some points in the original post. The proposal meant to add
> a new set of BLAS/LAPACK packages that are compiled in ILP64, and the
> existing BLAS/LAPACK API/ABI won't be changed and nothing will break.
>
> Here is a detailed example for demonstration
>
> src:openblas
> bin:libopenblas-base (LP64, won't be changed at all)
> provides libblas.so.3
> bin:libopenblas-dev (LP64, won't be changed at all)
> provides libblas.so
> bin:libopenblas-ilp64 (ILP64, newly-added)
> provides libblas-ilp64.so.3
> bin:libopenblas-ilp64-dev (ILP64, newly-added)
> provides libblas-ilp64.so
>
> So there is no "ABI bump" but just "adding a new set of ABI". At the
> same time, it won't result in any transition or breakage.
The way we manage different basic ABIs in Debian is to define separate
Debian architectures. E.g. on x86-64 we have the amd64 (LP64) and x32
(ILP32) architectures.
How you can use an ILP64 library without also building applications for
ILP64? And then, don't you also need libc6 built for ILP64?
> > I wondered about this. The mail said that the BLAS/LAPACK ABIs do not
> > change, so I presumed that this was about internal data layouts for
> > the data being passed which. But reading the bugreps it does sound
> > like just a new ABI using ILP64. That would be properly done using
> > multiarch or multilib paths, and needs some thought about how best to
> > lay things out and what else would be needed to make it work.
>
> The simplest solution is just to create a separate ABI with different
> name and different package name. And it introduces the least overhead.
It might seem simple, but can the added ABI really be limited to just a
few library packages?
> > Are any
> > other packages likely to start wanting to use ILP64 ABIs? I guess it's
> > very much an 'HPC' sort of thing at the moment.
> >
> > So yeah, some clarification in order I think, and an explanation of use-cases.
>
> HPC is indeed a related use case. I don't know any other package that
> would need such an ILP64 BLAS/LAPACK interface except for Julia.
> Actually by default Julia uses ILP64 version of openblas instead of
> LP64, see [julia-ilp64-default].
>
> Here are some references:
>
> 1. https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-ilp64-interface-vs-lp64-interface
>
> The Intel MKL ILP64 libraries use the 64-bit integer type (necessary
> for indexing large arrays, with more than 231-1 elements), whereas
> the LP64 libraries index arrays with the 32-bit integer type.
[...]
The correct C types for indexing arrays are ptrdiff_t and size_t.
These are already 64-bit in LP64 ABIs. So this seems like a workaround
for code using the wrong types.
Ben.
--
Ben Hutchings
Knowledge is power. France is bacon.
Reply to: