You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The real problem here was our CI testing, we need some tests running with AVX support. Our wheels are too generic for that, so problems won't manifest there. @tylerjereddy Do you know if it is possible to specify the hardware/flags on any of our testing platforms so that in the future problems like this will be caught early?
most testing platforms should have at least avx by now, I'd convert the code to runtime detection and add environment variables to select what you want for tests during the initial dispatching.
The current gain of this extra code is zero on hardware I tested so one could argue to just remove it, but if we extend the code to the boolean code we might see some actually reproducable benefits and adding some more selection features would be a worthwhile investment.
(note we already have compiler optimized runtime dispatched vector code in all our the integer ufuncs, there we simply rely on the correctness of the compiler compiling both the vectorized and normal code correctly but explicitly testing both code paths might still be worthwhile)
I can reproduce what Chuck sees at the offending commit with this compilation: CFLAGS=-mavx2 NPY_DISTUTILS_APPEND_FLAGS=1 python runtests.py --mode=full -- -n 7 -rsx
However, even on master branch, my Mac has a few new failures when compiling NumPy with -mavx2. On Azure, "illegal instruction" shows up right away when doc testing starts after a successful build for the Mac image with the above compile flags.
What's the "recommended" / conservative way to activate AVX(2) support for NumPy compile with clang and / or gcc? If this is an avx2 specific issue, I suppose we may need to probe a few different CI configs to see which has a sufficiently-recent CPU arch.
I don't think we have much control over specific hardware details, but we can certainly control compilation flags.
Activity
juliantaylor commentedon Dec 16, 2018
posted a fix to master and 1.16.x
charris commentedon Dec 16, 2018
The real problem here was our CI testing, we need some tests running with AVX support. Our wheels are too generic for that, so problems won't manifest there. @tylerjereddy Do you know if it is possible to specify the hardware/flags on any of our testing platforms so that in the future problems like this will be caught early?
juliantaylor commentedon Dec 16, 2018
most testing platforms should have at least avx by now, I'd convert the code to runtime detection and add environment variables to select what you want for tests during the initial dispatching.
The current gain of this extra code is zero on hardware I tested so one could argue to just remove it, but if we extend the code to the boolean code we might see some actually reproducable benefits and adding some more selection features would be a worthwhile investment.
(note we already have compiler optimized runtime dispatched vector code in all our the integer ufuncs, there we simply rely on the correctness of the compiler compiling both the vectorized and normal code correctly but explicitly testing both code paths might still be worthwhile)
tylerjereddy commentedon Dec 17, 2018
I can reproduce what Chuck sees at the offending commit with this compilation:
CFLAGS=-mavx2 NPY_DISTUTILS_APPEND_FLAGS=1 python runtests.py --mode=full -- -n 7 -rsxHowever, even on master branch, my Mac has a few new failures when compiling NumPy with
-mavx2. On Azure, "illegal instruction" shows up right away when doc testing starts after a successful build for the Mac image with the above compile flags.What's the "recommended" / conservative way to activate AVX(2) support for NumPy compile with clang and / or gcc? If this is an avx2 specific issue, I suppose we may need to probe a few different CI configs to see which has a sufficiently-recent CPU arch.
I don't think we have much control over specific hardware details, but we can certainly control compilation flags.