Re: I want to merge some BLAS updates to get things in a future-proof shape before the branch. Please review.

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Fri, 11 Jun 2021 08:03:09 -0400
schrieb Greg Troxel <gdt%lexort.com@localhost>: 

>   This is not really about CPU type at all, but whether the BLAS world
>   uses uint32 or uint64 as array indexes (and hence a different ABI).

Yes. It's because it comes from Fortran, where you traditionally just
used a default integer type that also happens to match the default
floating point type (single precision). You can tell the compiler to
change the size of the default types, so building a 64 bit variant is
trivial.

>  Therefore, the default should be 32 on 32-bit CPU types, because
>  problems that don't fit in RAM can't be addressed anyway.
>
>  Therefore, the default should be 64 on 64-bit CPU types because it's
>  not reasonable to limit problem sizes to 2^32 on architectures that
>  don't have the built-in limit.
>
> If that's what you mean, sounds good.  If not, please explain.

You got it. This is the idea.

> Based on that and my very
> fuzzy understanding, adding the 64-bit ABI seems ok, and defaulting to
> it, not. 

Agreed. My main point that influences the defaults is the header
directories also for netlib cblas and lapacke (with symlinks) and the
change to openblas packages to also include the C APIs. The main
consumer of that is numpy, which I of course will test into the freeze.

The option to use the 64 bit variants as dependencies might appear in
time, but it will not be the default until the next freeze at least.

A design decision to discuss is the handling of blas/blas64 generic
dependencies.

BLAS_C_INTERFACE=yes
BLAS_INDEX64=yes
.include ../../mk/blas.buildlink3.mk

vs. either

.include ../../mk/blas64.buildlink3.mk

or

.include ../../mk/blas.buildlink3.mk


The separte files would be mutually exclusive anyway.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg