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

Make qsimcirq Apple Silicon (M1, M2, ARM64) compatible and improve build scripts #643

Merged
merged 21 commits into from
Nov 29, 2023

Conversation

basnijholt
Copy link
Contributor

I've been working on compiling qsimcirq for conda-forge (conda-forge/staged-recipes#24504) and encountered several challenges with the existing CMake scripts, particularly for Linux and MacOS x86 platforms.

This PR introduces modifications that ensure successful builds on these platforms. Additionally, I've extended support to Apple Silicon (ARM architecture), focusing on compiling qsim_basic due to the unavailability of most CPU instruction sets on ARM.

This inclusion is particularly beneficial for developers who use MacBook M1 laptops, as it enables them to write and test code on their local machines and seamlessly run the same code on more powerful computational clusters.

Looking ahead, I plan to submit another PR to improve CUDA builds, further enhancing qsimcirq's performance and compatibility.

I kindly request a review from @95-martin-orion, @jakurzak, and @sergeisakov, as your insights would be invaluable. Your feedback will help ensure that these changes align well with qsim's development goals.

This PR aims to resolve the following issues:

Thank you for considering these changes!

@95-martin-orion 95-martin-orion added the kokoro:run Trigger Kokoro builds for this PR. label Nov 20, 2023
@qsim-qsimh-bot qsim-qsimh-bot removed the kokoro:run Trigger Kokoro builds for this PR. label Nov 20, 2023
@95-martin-orion
Copy link
Collaborator

Thanks for your contribution @basnijholt !

A couple requests regarding tests and release:

  1. This PR fails the current (non-Silicon) MacOS tests (logs). These are defined in this Github Actions workflow, which will need to pass before this PR can merge.
  2. Our Github Actions workflows for testing and releasing wheels don't currently include Apple Silicon wheels. These are now available for use - if you can add them, users on Apple Silicon will be able to pip install qsimcirq instead of having to build the wheels locally.

And a final word of caution: as you may have already noticed, qsim_basic is considerably slower than other qsim modes due to the lack of vectorization. For the use case you describe (testing locally, then running the same code on non-ARM64 machines) this shouldn't be an issue, but other use cases may be adversely impacted. In those cases, I still recommend the other options listed here - in particular, Google Colab is a highly portable solution for < 28 qubits.

Copy link
Collaborator

@sergeisakov sergeisakov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. In general, it looks good to me. Here is just one small thing in addition to @95-martin-orion's requests.

pybind_interface/decide/decide.cpp Outdated Show resolved Hide resolved
@basnijholt
Copy link
Contributor Author

basnijholt commented Nov 27, 2023

@95-martin-orion, thanks for your review. I will address your points.

In the meantime, could you enable workflow runs for any of my pushes? Right now it is pending approval on every commit.
edit: I enabled them on my own fork: basnijholt#1

Seems related:

@basnijholt
Copy link
Contributor Author

Awesome! @95-martin-orion @sergeisakov, on my fork the CI passes and builds Wheels for MacOS x86_64 and ARM64 successfully ✅:tada:

I would really appreciate if you could take another look. I believe I addressed all concerns.

@95-martin-orion
Copy link
Collaborator

Some recent Github outages broke the CI pipeline. Could you make a fresh commit? I'll trigger the necessary approvals.

@basnijholt basnijholt closed this Nov 27, 2023
@basnijholt basnijholt reopened this Nov 27, 2023
@basnijholt
Copy link
Contributor Author

@95-martin-orion, I just closed and opened the PR, which should retrigger the CI too.

@95-martin-orion 95-martin-orion added the kokoro:run Trigger Kokoro builds for this PR. label Nov 27, 2023
@qsim-qsimh-bot qsim-qsimh-bot removed the kokoro:run Trigger Kokoro builds for this PR. label Nov 27, 2023
@basnijholt
Copy link
Contributor Author

Awesome! The CI pipelines have all passed 🎉

Anything else I can do? 😄

@sergeisakov sergeisakov added the kokoro:run Trigger Kokoro builds for this PR. label Nov 28, 2023
@qsim-qsimh-bot qsim-qsimh-bot removed the kokoro:run Trigger Kokoro builds for this PR. label Nov 28, 2023
Copy link
Collaborator

@sergeisakov sergeisakov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@95-martin-orion 95-martin-orion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @basnijholt! I'll cut a release to make this available via pip install.

@95-martin-orion 95-martin-orion merged commit de65341 into quantumlib:master Nov 29, 2023
17 checks passed
@mpharrigan
Copy link

do we have a tracking bug for actually supporting fast execution on apple silicon architectures? could be cool

@95-martin-orion
Copy link
Collaborator

do we have a tracking bug for actually supporting fast execution on apple silicon architectures? could be cool

I don't think we have plans to support this. Apple Silicon (and ARM64 in general) doesn't have the SSE or AVX instruction sets, so supporting them would essentially require a total rewrite of qsim from the bottom up.

@basnijholt
Copy link
Contributor Author

If I find the time and motivation I could look in writing a Metal implementation.

@kgantchev
Copy link

do we have a tracking bug for actually supporting fast execution on apple silicon architectures? could be cool

Might I make a suggestion? You can try FlyCI's M1 and M2 runners. Our runners are on average 2x faster and 2x cheaper than GitHub's AND we have a free tier for OSS projects (see below).

Install Instructrions

Easily replace your M1 runners:

jobs:
 ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m1
   steps:
   - name: 👀 Checkout repo
     uses: actions/checkout@v4

Or try the M2 runners:

jobs:
  ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m2
    steps:
      - name: 👀 Checkout repo
        uses: actions/checkout@v4

Pricing

Processor vCPU RAM (GB) Storage Label Price on FlyCI Price on GitHub
M1 4 7 28 GB flyci-macos-large-latest-m1 $0.06 -
M1 8 14 28 GB flyci-macos-xlarge-latest-m1 $0.12 $0.16
M2 4 7 28 GB flyci-macos-large-latest-m2 $0.08 -
M2 8 14 28 GB flyci-macos-xlarge-latest-m2 $0.16 -

500 mins/month Free for Public Repos

If your repo is public, then FlyCI offers 500 mins/month of free M1 runner usage with the flyci-macos-large-latest-m1 runner.

Best Regards,
Kiril Gantchev
CEO and co-founder of FlyCI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants