Web lists-archives.com

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK




Le lundi 22 octobre 2018 à 18:38 +0100, Simon McVittie a écrit :
> On Mon, 22 Oct 2018 at 18:17:32 +0100, Ben Hutchings wrote:
> > On Mon, 2018-10-22 at 15:07 +0000, Mo Zhou wrote:
> > > 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.
> 
> Do BLAS/LAPACK really mean ILP64, or do they really mean "ABI with large
> array indexes"?

The latter. This is why I think that "ILP64" is a misnomer, and should
not be used for labeling the newly introduced libraries.

The ambiguity arises from the fact that some BLAS/LAPACK
implementations are written in Fortran, and use the default integer
type for array indexes. Hence the solution is to compile them with
-fdefault-integer-8. But this does not mean that this code is really
ILP64, because it's not C and hence it does not uses the C ABI. Only
integers exposed through the BLAS/LAPACK ABI are affected (most of them
are array indices, the remaining others are return codes).

For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they
will be compiled using LP64, and not ILP64. Only integers exposed
through the interface will be affected, through the use of appropriate
types.


Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

Attachment: signature.asc
Description: This is a digitally signed message part