Repository navigation
ENH: Provide Windows ARM64 wheels #22530
Description
Proposed new feature or change:
Currently there are no Windows ARM64 wheels (ending with -win_arm64) provided for NumPy on PyPI. cibuildwheel started supporting cross-compiling Windows ARM64 wheels with their 2.11 release, which is currently used in NumPy.
Activity
charris commentedon Nov 4, 2022
Note that we could also add pp39 wheels. @mattip Thoughts?
mattip commentedon Nov 4, 2022
If it is not too much burden, pp39 wheels would be nice.
rgommers commentedon Nov 5, 2022
Windows ARM64 wheels were discussed in https://mail.python.org/archives/list/[email protected]/thread/FRACXJ2LERKB2UC5SFIXL2FEA5XPNPRW/#FRACXJ2LERKB2UC5SFIXL2FEA5XPNPRW. It's a bit too early for that; no one can test them.
andyfaff commentedon Jun 26, 2023
How about providing them as nightly-only?
EwoutH commentedon May 24, 2024
Considering Microsoft and Qualcomm are making a big push towards Windows Arm64, it might be interesting to revisit this issue.
andyfaff commentedon May 24, 2024
cibuildwheel supports cross compiling, https://cibuildwheel.pypa.io/en/stable/faq/#windows-arm64.
It says in that section:
I'm not sure what that means for numpy, we use mesonpy as the build backend. One can cross compile using meson, but it's not the easiest to get to work.
rgommers commentedon May 24, 2024
Even if the build works, cross-compiling without being able to run the tests isn't all that useful (the end result is pretty likely to be broken). We are not going to be able to do much here without either a native CI runner or workable emulation I think.
Are they? It's going at a glacial pace as far as I can tell. Still almost no hardware available, and no CI support. The mailing list message linked above is almost 2 years old, not much has changed.
EwoutH commentedon May 24, 2024
@zooba if there is one single project where a little push can potentially have a large effect, it's this one. NumPy is the bedrock of the Python scientific ecosystem. If you see anything you think you might be able to assist with, please let us know :)
rgommers commentedon May 24, 2024
Also, for reference: I'm aware of conda-forge wanting to support Windows on Arm. That's a much nicer strategy until CI runners become available - it worked really well when macOS switched to arm64.
zooba commentedon May 24, 2024
Yeah, that's our influence. It's so much easier to work with a single organisation to provide (virtual) hardware and tech support to get builds going, compared to every individual project. But that's been slow moving as well. We're not in a position to do anything but ask nicely, and for the most part say "trust us, people will want this". Having new, faster hardware, as well as better virtual hardware, coming out ought to help the motivation, although nothing about the architecture has really changed in that time.
There's been hardware generally available for a while now, but not widely used. We jumped in pretty early to let the important projects know and make sure they can build - possibly too early, at least for the stuff we could say in public 😉 This latest round of devices will grow that, but the strategy of "we're killing all the old stuff as soon as we can" just isn't something Microsoft will ever do, so it's going to look glacial compared to other platforms.
Last we tested, we know that Numpy built and ran fine on Windows ARM64 (thanks to contributions), but there's been a lot of work done since then. We're looking at it again to make sure our understanding is up to date, but we're deliberately trying not to take any autonomy away from projects, so we're not going to ship anything - just use what we find to help the projects get ahead of changes they'll need to make. We're also hoping to figure out with NumFOCUS how to provide infrastructure through them, which would flow to Numpy.
EwoutH commentedon Jun 19, 2024
Official GitHub blog:
So it's coming. Maybe NumPy can request early access to these runners.
zooba commentedon Jun 19, 2024
If I'm able to get projects early access, then NumPy is high up on the list.
cgohlke commentedon Jun 19, 2024
FWIW, I am using Python for Windows on ARM64 on a Windows Dev Kit 2003. It's working well for me. For example, latest numpy and scipy pass all tests with OpenBLAS. I shared my builds at https://github.com/cgohlke/win_arm64-wheels/.
44 remaining items
ENH: Provide Windows 11 ARM64 wheels (numpy#22530)
HinTak commentedon Apr 26, 2025
This is my first ever contribution to numpy - #28836 - I hope the pull fits in well with existing practices.
I am doing this mostly because I co-maintain skia-python and numpy is one of its dependencies.
We have a request for arm windows wheel recently. The dependency of skia-python on numpy is mostly in converting graphic bitmaps to and from byte arrays, and a noOpenBlas numpy is sufficient.
rgommers commentedon May 5, 2025
Request for input: given that OpenBLAS WoA builds may not be ready in time before 2.3.0rc1, shall we ship experimental wheels without OpenBLAS yes or no? gh-28836 is about ready modulo that decision. Copying from my comment there:
The one thing I'm doubting is whether we should merge the wheel build part, since it's going to be quite slow without OpenBLAS. But perhaps it's still better than nothing - not many people will be able to build with a BLAS library from scratch anyway. So I think I'm okay with merging this and then updating after MacPython/openblas-libs#193 lands to provide
scipy-openblas64wheels.zooba commentedon May 5, 2025
I vote for distributing the wheel without OpenBLAS - there are a number of other libraries that can't even start trying out WoA builds because numpy isn't available, and so those would be unblocked.
ARM64 is still experimental for upstream CPython, so users shouldn't get themselves into an unoptimised version by mistake (or rather, it won't be their first mistake 😉 )
matthew-brett commentedon May 5, 2025
How long do we have to decide? Given we already have the openblas WoA wheels building via the script at MacPython/openblas-libs#193, it should be little work to get the running on the Github runners - a day or so.
rgommers commentedon May 5, 2025
It's very easy to change, as soon as OpenBLAS is available. There's a couple of weeks before branching, but I'd rather merge the CI jobs in gh-28836 now and update them after, rather than leave that PR sitting there until the branch date is very close.
HinTak commentedon May 5, 2025
What do you mean by "slow"? The build time for arm windows is not significantly different from the others, https://github.com/HinTak/numpy/actions/runs/14681658381 (and earlier experiment from which I cleaned up to do the pull), and that include pytest. It is in parallel to 32-bit noblas windows and others anyway.
rgommers commentedon May 5, 2025
Performance, but build time - not linking against BLAS can give factors of 10x to 100x slowdowns on anything that involves linear algebra.
HinTak commentedon May 5, 2025
The build time is inclusive of pytest and I assume that includes some use of linear algebra? I understand some will want to use numpy with linear algebra, but some python packages have numpy as a dependency for data exchange. I guess we could wait a few days and see if opennblas on arm windows is forth coming.
HinTak commentedon May 5, 2025
Also.the non- CI part of #28836 - a few tests need to be skipped due to interaction with meson / mingw objdump etc - is going to be still valid, I think
charris commentedon May 5, 2025
+1. Best get an early start. Having anything available is a good start, and avoiding backports makes my life easier.
Merge pull request #28836 from HinTak/windows-arm64-support
ENH: Provide Windows 11 ARM64 wheels (numpy#22530)