-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
TEST: 1.8.x + blas variants #199
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
b986b4b
to
b2f9c58
Compare
Scipy 1.8.0TL;DR: A quarter** of relevant combinations is failing in some way, and that's not even counting pypy (or the propack segfaults)From 30 failures out of 96 runs for 1.7.3, we're now at 6 segfaults and 15 failures out of 66 CI runs (dropping cpython 3.7 & pypy 3.7, adding accelerate for osx, switching split of avx512 presence/absence from blis to mkl) ** discounting the 6 PPC failures, which are due to emulation Notable:
The good news:
The bad news:
Details
** sum of Segfaults (S), Failures (F), resp. Timeouts (T); out of a total of 66 CI combinations being tested Build logs: (linux / windows) + mkl + avx512: 1 failure
Also, at the end of the test suite, some (seemingly delayed) log output appears that is perhaps relevant:
windows + openblas: 3 failures
|
Is there someone who cares about the re-enabled Accelerate who can isolate the problems and file new issues? Given that everything gets built with the same g77 ABI and Netlib/OpenBLAS work fine it seems clear that there's an Accelerate issue here. I'm happy to forward the bug reports to Apple to see if they want to prioritize fixes. |
The accelerate stuff in conda-forge is very recent, and not just plain vanilla either - we're using BLAS from accelerate and LAPACK from netlib (because LAPACK from accelerate is too old). I think it's possible that there are still issues on our side after this relatively short incubation time, and maybe not yet the time to bug Apple. CC @isuruf |
@rgommers I am happy to help with this if you give me a brief overview (additional context besides the thread from previous convos) on things to look for. I was pushing for wider adoption of Accelerate a few weeks ago, but I have since concluded that it would likely not be worth it (largely in alignment with the scipy maintainers' argument). I recently started using scipy for a side project and I have been super happy/impressed by some accelerations I got via FITPACK, so I am happy to do what I can in return and learn more about the workings of scipy anyway :) Let me know what would be most helpful here |
@h-vetinari my impression (via @isuruf) was that the segfaults were only on osx-arm. Just to confirm: are they also present on osx-64? |
It's the other way around: osx-64 builds are segfaulting, but that's very likely because that's the only osx flavour we have CI for. I expect a very high likelihood that the osx-arm64 builds are also segfaulting with the current scipy-builds. |
b2f9c58
to
de4847e
Compare
b43b18e
to
076b309
Compare
…nda-forge-pinning 2023.01.26.16.59.55
076b309
to
1dee1bb
Compare
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Scipy 1.8.1I had originally picked this up in mid 2022, but despaired based on the number of different failures. Now picking this up again to have a reasonable chain record of the changes from here to 1.10. TL;DR: Some persistent failures, but less segfaults; cautious improvements overallFrom 6 segfaults and 15 failures out of 66 runs for 1.8.0, we're now at 0 segfaults and 40 failures out of 110 CI runs (re-added PyPy) The good news:
The bad news:
ALL builds fail the following tests:
To avoid a completely red matrix below, I'm discounting those failures from each build detailed stacktrace
Details
Matrix below is discounting the above-mentioned 7 failures present in all builds
** sum of Segfaults (S), Failures (F), resp. Timeouts (T); out of a total of 110 CI combinations being tested Build logs: Failures in addition to the 7 mentioned abovelinux + mkl + avx512: 2 additional failures
linux + netlib + avx512: 1 additional failure
linux + netlib + non-avx512: 2 additional failures
linux + openblas + avx512: 3 additional failures
linux + {x86, aarch} + openblas + non-avx512: 2 additional failures
windows + mkl + avx512: 1 additional failure
windows + openblas + avx512: 9 additional failures
windows + openblas + non-avx512: 8 additional failures
osx + accelerate: 8 additional failures
osx + mkl: 2 additional failures
osx + openblas: 3 additional failures
|
I see we have this now for 1.8.x, 1.9.x and 1.10.x - that's a bit much to look at. Should we close this and focus on 1.10.x? |
I tend to close the old ones as they become obsolete, but in this case, I wanted to establish the progression from 1.8 to 1.10, and wanted to have a baseline for that (especially as I had missed redoing this for anything after 1.8.0). It's more for historical reference and interested - feel free to skip ahead to 1.10. In any case, this PR can be closed indeed. |
Following the same scheme as #172, #153 & #130. Should not be merged for the same reasons as #153.