Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Windows on Arm #11472

Open
3 tasks done
pbo-linaro opened this issue May 13, 2022 · 21 comments
Open
3 tasks done

Support for Windows on Arm #11472

pbo-linaro opened this issue May 13, 2022 · 21 comments
Assignees
Labels
in-progress issue is actively being worked on os::windows relevant to Windows source::community catch-all for issues filed by community members source::partner created by or for an Anaconda, Inc. partner company type::feature request for a new feature or capability

Comments

@pbo-linaro
Copy link

Checklist

  • I added a descriptive title
  • I searched for other feature requests and couldn't find a duplicate (including also the type-feature tag)
  • I confirmed that it's not related to another project (see the above section)

What is the idea?

Hi, Linaro is currently working with Microsoft to enable a lot of open source projects to run on Windows on Arm.

We are currently investigating if conda could be easily enabled for this new architecture.
The main blocking point today is the lack of "free" Windows on Arm machines in CI systems.
Azure started deploying Arm server, but this is not a free solution.

Thus, we are targetting cross compilation for now, and we would like to experiment with it, before offering any official support.

Why is this needed

Microsoft is investing a lot of effort in this new architecture, and the numbers of users is growing steadily.

Since conda allows to distribute a lot of software, it is a great way to support a lot of projects through it.

What should happen?

So far, I'm trying to build a package for this new architecture on a custom channel at anaconda.org.

I added a conda_build_config.yaml:

target_platform:
  - win-arm64

I started with a recipe without any dependencies.
conda-build insists on finding ...\conda-bld\win-arm64\repodata.json, which, of course, is not available at the time.
I managed to bypass this by copying it (locally) from win-64 arch.

Is a support needed on anaconda side to make it work?


After that, I tried to compile a C package. Alas, due to the absence of repodata.json, no compiler package can be found.
Is there a way to define it locally, so I can at least try to build a few packages?


I didn't manage to find useful documentation on porting to new architecture, which, I can understand, is not very frequent.
Where is the best place to get information on this?

Thanks,
Pierrick

Additional Context

No response

@pbo-linaro pbo-linaro added the type::feature request for a new feature or capability label May 13, 2022
@pbo-linaro
Copy link
Author

Polite ping :) Does anyone has experience with porting conda to new architectures?

@isuruf
Copy link
Contributor

isuruf commented May 31, 2022

cc @chenghlee, @jezdez

@chenghlee chenghlee self-assigned this Jun 1, 2022
@chenghlee chenghlee added os::windows relevant to Windows source::community catch-all for issues filed by community members sync::anaconda sync internally with Anaconda, Inc. ticket tracker labels Jun 1, 2022
@chenghlee
Copy link
Contributor

@pbo-linaro Enabling Windows on ARM support requires a few things, some easier than others.

  1. Getting conda and conda-build to recognize Windows on ARM as an "official" platform/subdir. This is fairly easy, but we will need to know what CPython reports for sys.platform, platform.machine(), and platform.architecture() on this platform. (The biggest question I have at the moment is whether the CPU architecture is reported as aarch64 or arm64.) For reference, the PRs to enable osx-arm64 as a platform include:

  2. Anaconda.org need to recognize Windows on ARM as an "official" platform/subdir. This change needs to be made by Anaconda, and I've created Enable win-arm64 as a platform on anaconda.org ContinuumIO/anaconda-issues#12957 as a public tracking issue. (Technically speaking, anaconda.org already allows uploading and downloading of win-arm64 packages, but some of UI and API niceties aren't available until the backend server recognizes this platform.)

  3. Package build out. This is probably the biggest and most complicated lift; to the best of my knowledge, no clear, definitive guides for how to bootstrap new platforms exist. However, both Anaconda and conda-forge have bootstrapped new platforms fairly recently, and I would suggest reaching out to both. (Anaconda via the "Partnerships" option at https://www.anaconda.com/contact; and conda-forge at https://github.com/conda-forge/conda-forge.github.io/issues)

@pbo-linaro
Copy link
Author

Thanks for taking time to detail steps needed, that's very helpful.

  1. For now, arch is reported as ARM64. Is that fine for conda to detect it?
Python 3.10.3 (tags/v3.10.3:a342a49, Mar 16 2022, 12:16:06) [MSC v.1929 64 bit (ARM64)] on win32
>>> sys.platform
'win32'
>>> platform.machine()
'ARM64'
>>> platform.architecture()
('64bit', 'WindowsPE')
  1. Thank for your creating this issue. We didn't know precisely where to ask.
  2. We'll do for sure once this architecture is recognized!

@chenghlee
Copy link
Contributor

For now, arch is reported as ARM64. Is that fine for conda to detect it?

Yes; we just need to know if Python on Windows was going to use the macOS name (arm64), the Linux name (aarch64), or something else when reporting the machine name/CPU architecture.

@pbo-linaro
Copy link
Author

pbo-linaro commented Jun 7, 2022

@chenghlee Both of us are working on this: @pbo-linaro, @nsait-linaro

@chenghlee chenghlee added the backlog issue has been triaged but has not been earmarked for any upcoming release label Jun 15, 2022
@beeankha beeankha removed the sync::anaconda sync internally with Anaconda, Inc. ticket tracker label Aug 30, 2022
@jakirkham
Copy link
Member

cc @zooba (for awareness)

@jezdez jezdez self-assigned this Apr 17, 2023
@jezdez jezdez added this to the 23.7.0 milestone Apr 17, 2023
@jezdez jezdez added the source::partner created by or for an Anaconda, Inc. partner company label Apr 17, 2023
@jezdez
Copy link
Member

jezdez commented Apr 17, 2023

@zooba Can you answer if the values in #11472 (comment) are the ones in current builds of Python for arm64?

@zooba
Copy link

zooba commented Apr 17, 2023

Yes. However, the two main detections we need are:

  • sys.winver.endswith("-arm64") to detect an ARM64 build of CPython
  • platform.processor() == "ARM64" to detect an ARM64 host OS

Because an ARM64 host can run x86 and x64 builds, just checking the processor isn't enough. But only an ARM64 host can run an ARM64 build, so if winver checks out then we're definitely on ARM64.

Also, the processor() call on 3.11 can be tricked by compatibility modes (it uses environment variables - in 3.12 it'll be more accurate). But if the winver check comes first, it won't matter.

platform.architecture() doesn't have an API that can return ARM64 - it's specified to return the number of bits in a pointer, which is 64.

Also, there's no standard way to specify that a build should be cross-compiled for ARM64. We get to invent one here (the variable used for setuptools is the one set by vcvarsall.bat, which may/may not be appropriate for conda).

@beeankha beeankha added the in-progress issue is actively being worked on label Jun 27, 2023
@kenodegard kenodegard moved this to 🆕 New in 🧭 Planning Jun 30, 2023
@jezdez jezdez modified the milestones: 23.7.0, 23.9.0 Jul 7, 2023
@kenodegard kenodegard removed the backlog issue has been triaged but has not been earmarked for any upcoming release label Jul 10, 2023
@kenodegard kenodegard removed this from the 23.9.0 milestone Jul 26, 2023
@kenodegard kenodegard moved this from 🆕 New to 🛑 Blocked in 🧭 Planning Jul 26, 2023
@jezdez
Copy link
Member

jezdez commented Jul 26, 2023

We're just removing the milestone for now, while we're working through the legal parts of this work.

@mortonmj
Copy link

mortonmj commented Apr 8, 2024

Can someone kindly provide an outlook/availability for this issue of conda supported/beta on Windows ARM?

Thank You

@EwoutH
Copy link

EwoutH commented May 27, 2024

With Microsoft's and Qualcomm's recent push for Arm64 Windows PCs, it might be interesting to reconsider this issue.

Microsoft Surface and our OEM partners Acer, ASUS, Dell, HP, Lenovo and Samsung, with [Snapdragon X] pre-orders beginning today and availability starting on June 18.

@zooba
Copy link

zooba commented May 28, 2024

A regular x64 conda will run fine on Windows ARM64, however, it will currently only install emulated binaries. conda itself can run fine on a native ARM64 Python (last time we tested it, anyway), so there's nothing to worry about there. It's up to conda-forge right now to add build support for every package to get a truly native ARM64 environment - best to show your interest over here.

I'm not sure what the "legal parts" Jannis mentioned in his last post refer to (unless it's the CLA?), so there may be some other things to do here. But this is not the project that needs the encouragement.

@tburnett
Copy link

I use the linux subsystem, which is not supported in that there is no miniconda. The above comment played a part in my decision to be one of the first to own a new Surface, but the x86 version would not load. So I have this wonderful machine now sort of useless. Hoping...

@zooba
Copy link

zooba commented Jun 19, 2024

If you're in WSL, then you're in Linux. You'll need an aarch64 build for Linux (probably, I haven't used WSL on ARM64 hardware, but I assume that's how it works).

The x86/x64 emulation I refer to above is a Windows feature, not a Linux feature.

@scw
Copy link
Contributor

scw commented Jun 25, 2024

A regular x64 conda will run fine on Windows ARM64, however, it will currently only install emulated binaries. conda itself can run fine on a native ARM64 Python (last time we tested it, anyway), so there's nothing to worry about there.

One area this isn't true for yet is packages which depend explicitly on AVX instructions since those aren't yet supported by the x64 emulation layer. A handful of packages don't perform dynamic dispatch but instead bind to the host architecture to pass on to the compiler for auto-vectorization.

@scw
Copy link
Contributor

scw commented Jun 25, 2024

The original post mentions the lack of Windows ARM CI systems, an update is GitHub Actions now have ARM images for both Windows and Linux in public beta.

@pbo-linaro
Copy link
Author

Indeed, but for now it's only for paid plans.

However, the blog article mentions they will open up this to public repositories by end of the year:

Arm runners are available to customers on our Team and Enterprise Cloud plans. We expect to begin offering Arm runners for open source and personal accounts by the end of the year.

This is a great thing, and will definitely help to support windows-arm64.

@zooba
Copy link

zooba commented Jun 26, 2024

conda-forge has ARM64 machines already available, so if you want to help get their recipes migrated to build up to and including conda, please do. (We donated a build pool while we wait for GitHub support to open up, as they're a single organisation with good coverage, which is far more efficient than trying to do individual projects.)

@maxwxyz
Copy link

maxwxyz commented Oct 11, 2024

Any news on this issue? The demand is growing for the native support.

@gilgaTheDev
Copy link

conda-forge has ARM64 machines already available,

Not yet, but it's growing... conda-forge/conda-forge.github.io#1940

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in-progress issue is actively being worked on os::windows relevant to Windows source::community catch-all for issues filed by community members source::partner created by or for an Anaconda, Inc. partner company type::feature request for a new feature or capability
Projects
Status: 🛑 Blocked
Development

No branches or pull requests