tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

"Dr. Thomas Orgis" <> writes:

> commit f3668144b0bdad5f5f3e3dc3aef000d6716d5264 (HEAD -> master, origin/master, origin/HEAD)
> Author: Dr. Thomas Orgis <>
> Date:   Thu Jun 10 19:51:22 2021 +0200
>     blas64, lapack64, cblas*, lapacke*, openblas*, mk/blas64.bl3: fixup and 64 bit BLAS
>     This prepares for 64 bit index BLAS libraries alongside 32 bit ones. In preparation
>     of better support for vendor BLAS libraries, I had to realize that you better
>     use the C interfaces supplied by them, not the netlib one strapped on. A simple
>     reason of practicability: The vendor blas libraries, like openblas, like to
>     ship all symbols in one library, so you get them whether you want it or not.

My read of this is that this is, perhaps of, but highlighting things
that could maybe be clearer:

  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).

  For reasons that may or may not be valid but which are beyond the
  scope of pkgsrc and thus not to be worried about, BLAS used a 32-bit
  fixed-width type for array indices rather than the native int (from
  the C ABI).

  However, given that one can run 32-bit or 64-bit indices on either 32-
  or 64-bit processors (actually, on all of ILP32, LP64 and ILP64), it
  makes sense to allow a choice of BLAS ABIs, because the 32-bit size is
  faster/less-space for uses where it is big enough.

  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.

Freezes typically start sometime between 15th and 20th, and the the norm
is that everything is working ok going into the freeze, with of course
some things not that we fix, but changes should be made with the 95%+
expectation of being at at freeze start.  Based on that and my very
fuzzy understanding, adding the 64-bit ABI seems ok, and defaulting to
it, not.  But all I really care about is that things are mostly ok at
freeze start.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index