Detect the Apple Accelerate/vecLib runtime

[ogrisel]

It is now possible to install numpy, scipy... with a BLAS implementation that links to the macOS Accelerate library via conda-forge:

• Option to install numpy built with Apple's Accelerate BLAS implementation conda-forge/numpy-feedstock#253

But at the moment, threadpoolctl does not recognize this BLAS implementation. I tested the following on a macOS/M1 machines:

mamba create -n accelerate numpy "libblas=*=*accelerate" threadpoolctl
mamba activate accelerate
python -m threadpoolctl -i numpy
[]

Output of mamba list:

# packages in environment at /Users/ogrisel/mambaforge/envs/accelerate:
#
# Name                    Version                   Build  Channel
bzip2                     1.0.8                h3422bc3_4    conda-forge
ca-certificates           2022.12.7            h4653dfc_0    conda-forge
libblas                   3.9.0           16_osxarm64_accelerate    conda-forge
libcblas                  3.9.0           16_osxarm64_accelerate    conda-forge
libcxx                    15.0.7               h75e25f2_0    conda-forge
libffi                    3.4.2                h3422bc3_5    conda-forge
libgfortran               5.0.0           12_2_0_hd922786_31    conda-forge
libgfortran5              12.2.0              h0eea778_31    conda-forge
liblapack                 3.9.0           16_osxarm64_accelerate    conda-forge
libsqlite                 3.40.0               h76d750c_0    conda-forge
libzlib                   1.2.13               h03a7124_4    conda-forge
llvm-openmp               16.0.0               h7cfbb63_0    conda-forge
ncurses                   6.3                  h07bb92c_1    conda-forge
numpy                     1.24.2          py311h60f8152_0    conda-forge
openssl                   3.1.0                h03a7124_0    conda-forge
pip                       23.0.1             pyhd8ed1ab_0    conda-forge
python                    3.11.0          h3ba56d0_1_cpython    conda-forge
python_abi                3.11                    3_cp311    conda-forge
readline                  8.2                  h92ec313_1    conda-forge
setuptools                67.6.0             pyhd8ed1ab_0    conda-forge
threadpoolctl             3.1.0              pyh8a188c0_0    conda-forge
tk                        8.6.12               he1e0b03_0    conda-forge
tzdata                    2023b                h71feb2d_0    conda-forge
wheel                     0.40.0             pyhd8ed1ab_0    conda-forge
xz                        5.2.6                h57fd34a_0    conda-forge

Even if we cannot detect the number of threads it would be helpful to detect that numpy and/or scipy rely on Accelerate.

For CI purposes, we could probably leverage Cirrus CI to gain access to macOS/arm64 machines. Alternatively we could try with the standard macOS/x86_64 CI on Azure.

EDIT: GitHub Actions now also has macOS M1 runners by default.

[ogrisel]

For information:

otool -L /Users/ogrisel/mambaforge/envs/accelerate//lib/libblas.3.dylib
/Users/ogrisel/mambaforge/envs/accelerate//lib/libblas.3.dylib:
	@rpath/libvecLibFort-ng.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0, reexport)
	@rpath/liblapack-netlib.3.9.0.dylib (compatibility version 0.0.0, current version 0.0.0, reexport)
	@rpath/liblapacke-netlib.3.9.0.dylib (compatibility version 0.0.0, current version 0.0.0, reexport)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)

so we would need to both inspect the libBLAS.dylib filename and one of its ancestor folders such as vecLib.framework or Accelerate.framework to detect this.

[rgommers]

I'll note that NumPy now defaults to building against the new Accelerate BLAS and LAPACK (not like conda-forge, that's old Accelerate + Netlib BLAS). It would indeed be quite useful. How it's reported by numpy right now:

>>> np.show_config(mode='dicts')['Build Dependencies']['blas']
{'name': 'accelerate', 'found': True, 'version': 'unknown', 'detection method': 'system', 'include directory': 'unknown', 'lib directory': 'unknown', 'openblas configuration': 'unknown', 'pc file directory': 'unknown'}

[ogrisel]

@rgommers is this supposed to be the case for a released version of numpy or for the future numpy 2?

I just tried to install numpy from pypi.org in an empty tmp conda env and I got openblas:

$ mamba list numpy
# packages in environment at /Users/ogrisel/miniforge3/envs/tmp:
#
# Name                    Version                   Build  Channel
numpy                     1.26.4                   pypi_0    pypi

$ python -m threadpoolctl -i numpy
[
  {
    "user_api": "blas",
    "internal_api": "openblas",
    "num_threads": 8,
    "prefix": "libopenblas",
    "filepath": "/Users/ogrisel/miniforge3/envs/tmp/lib/python3.12/site-packages/numpy/.dylibs/libopenblas64_.0.dylib",
    "version": "0.3.23.dev",
    "threading_layer": "pthreads",
    "architecture": "armv8"
  }
]

EDIT: running on macOS / M1

[rgommers]

I just tried to install numpy from pypi.org in an empty tmp conda env and I got openblas:

It's a very recent regression, which got introduced in some CI refactor (the Accelerate wheel build jobs didn't have OpenBLAS installed until last week or so). That will definitely be fixed before 2.0 comes out.

[ogrisel]

numpy 2.0.0rc1 is out and ships wheels for macos-14 that no longer vendor openblas but instead link against the system Accelerate:

• https://pypi.org/project/numpy/2.0.0rc1/#files

So I guess the priority of this issue goes up because there will be many more people using Accelerate by default very soon.

[rgommers]

Relying on np.show_config is partially possible:

• If it does says accelerate then that means "the NEWLAPACK Accelerate introduced in macOS 13.3", and will be reliable (this will be the case for numpy wheels on PyPI for example).
• If it doesn't say accelerate then it's still possible that conda-forge is doing its "build against libblas stubs" thing and Accelerate is switched in dynamically. This is currently old-style Accelerate + Netlib LAPACK. Inspecting the output of otool -L seems like the only option to deal with that.