[Distutils] Status update on the NumPy & SciPy vs SSE problem?

[Nathaniel Smith]

On Feb 4, 2016 3:22 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> While the manylinux PEP brings Linux up to comparable standing with
> Windows and Mac OS X in terms of distributing wheel files through
> PyPI, that does mean it still suffers from the same problem Windows
> does in relation to NumPy and SciPy wheels: no standardisation of the
> SSE capabilities of the machines.
>
> I figured that was independent of the manylinux PEP (since it affects
> Windows as well), but I'm also curious as to the current status (I
> found a couple of apparently relevant threads on the NumPy list, but
> figured it made more sense to just ask for an update rather than
> trusting my Google-fu)

I'm not entirely sure what the SSE status is of the numpy OSX wheels. I
think that they may be just following Apple's guidance on this (in the
sense of: we tell their compiler to target a certain OS version and then
use default options beyond that), but I'm not sure. It may even differ
between the 32- and 64-bit "parts" of the fat binaries. Asking on
numpy-discussion might net more details.

Otherwise, yeah, the current plan is to jump to SSE2 as the minimum
required version as the new wheels become usable, since all the evidence
seems to say that it's ubiquitous now.

> P.S. I'm assuming the existing ability to publish NumPy & SciPy wheels
> for Mac OS X is based on Apple's tighter control of their hardware
> platform.

Not particularly. It's based on (a) Linux wheels aren't allowed on pypi
(modulo bugs -- see pypi issue #385), (b) windows wheels are impossible
because on that platform there's no F/OSS-compatible toolchain that can
build cpython-abi-compatible BLAS or scipy. So OSX is what's left after all
the competitors shot themselves in the foot :-)

(manylinux is the solution to (a); mingwpy.github.io is the solution to
(b).)

Once that stuff is solved then yeah, it might be nice to have some better
solution to the problem of ISA variations. But the most important part is
already handled by runtime cpu sniffing in the blas library, and for the
rest there are a variety of possible solutions (doing our own cpu sniffing,
or adding something to wheels, or etc.), and just in general figuring out
which solution is best is just not anywhere near the top of our priority
list when we still can't distribute binaries to most users at all :-)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160204/e074637f/attachment.html>