<p dir="ltr">On Feb 4, 2016 3:22 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> While the manylinux PEP brings Linux up to comparable standing with<br>
> Windows and Mac OS X in terms of distributing wheel files through<br>
> PyPI, that does mean it still suffers from the same problem Windows<br>
> does in relation to NumPy and SciPy wheels: no standardisation of the<br>
> SSE capabilities of the machines.<br>
><br>
> I figured that was independent of the manylinux PEP (since it affects<br>
> Windows as well), but I'm also curious as to the current status (I<br>
> found a couple of apparently relevant threads on the NumPy list, but<br>
> figured it made more sense to just ask for an update rather than<br>
> trusting my Google-fu)</p>
<p dir="ltr">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.</p>
<p dir="ltr">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>
<p dir="ltr">> P.S. I'm assuming the existing ability to publish NumPy & SciPy wheels<br>
> for Mac OS X is based on Apple's tighter control of their hardware<br>
> platform.</p>
<p dir="ltr">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 :-)</p>
<p dir="ltr">(manylinux is the solution to (a); <a href="http://mingwpy.github.io">mingwpy.github.io</a> is the solution to (b).)</p>
<p dir="ltr">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 :-)</p>
<p dir="ltr">-n</p>