-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
MAINT: Update openblas_support.py
to support Apple Silicon
#14316
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming you've read and dealt with the issues described here: #14188
openblas_support.py
to support Apple Siliconopenblas_support.py
to support Apple Silicon
I apologise, I did not! I was coming at this from a different perspective (from |
Ok, I don't know what to do about that set of issues, but maybe it will get more attention now that M1 support is gaining momentum. |
openblas_support.py
to support Apple Siliconopenblas_support.py
to support Apple Silicon
b376ffe
to
de82eb5
Compare
Not quite sure that that slowdown reported on gh-14188 is real. This PR: Another recent PR ( Yet another recent PR ( |
There's also much faster runs - timings jump around a lot. |
@rgommers Either way it looks like |
openblas_support.py
to support Apple Siliconopenblas_support.py
to support Apple Silicon
To fix linux-32bit test, try merging #14333 into this branch. |
Now the issue is that |
Why is this the problem? The only failure I see is We need one test with an old gfortran, otherwise we'll run into it at wheel build time. xref MacPython/scipy-wheels#111 which got stuck, we'd like to bump the minimum |
Actual error is,
That's because openblas-0.3.15 was built with gfortran 8 and you need |
Ah yes, I managed to overlook that build log output, thanks.
Hmm. I looked through the PRs on https://github.com/MacPython/openblas-libs and https://github.com/MacPython/openblas-libs. There's a bunch of upgrades, but it's not entirely clear to me if this was a necessary change. If we can make our wheels work with |
Linux 32bit and windows 32 bit both fail with the same error now. |
Would bumping the tolerances of that test be an acceptable solution as suggested? |
Rebased on master after the test refactor and 32-bit skips for |
Okay, shall revert these changes back to fortran-8. |
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
The pre release azure failure should go away--I just merged in Ralf's fix for that a minute ago. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All right, all green except for one unrelated CI issue that was fixed earlier today. It's time to merge this. Thanks a lot @judahrand and @isuruf!
Labelled for backport, I think |
…4316) This commit brings `scipy`'s implementation of this script into line with `numpy`'s. This includes an update of the OpenBlas version as well as support for `macosx-arm64`. The source implementation can be found here: https://github.com/numpy/numpy/blob/7ef28b2f1c383828bebcbb87b8e487e27c6e3ff9/tools/openblas_support.py Co-authored-by: Isuru Fernando <isuruf@gmail.com>
Reference issue
What does this implement/fix?
This commit brings
scipy
's implementation of this script into line withnumpy
's. This includes an update of the OpenBlas version as well as support formacosx-arm64
.The source implementation can be found here: https://github.com/numpy/numpy/blob/7ef28b2f1c383828bebcbb87b8e487e27c6e3ff9/tools/openblas_support.py
I believe this is needed before the checks on MacPython/scipy-wheels#123 will pass.
Additional information