<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 10:12 PM, Oscar Benjamin <span dir="ltr"><<a href="mailto:oscar.j.benjamin@gmail.com" target="_blank">oscar.j.benjamin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 4 December 2013 20:56, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>

> On Wed, Dec 4, 2013 at 5:05 PM, Chris Barker - NOAA Federal<br>
> <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
>><br>
</div><div class="im">>> So a lowest common denominator wheel would be very, very, useful.<br>
>><br>
>> As for what that would be: the superpack is great, but it's been around a<br>
>> while (long while in computer years)<br>
>><br>
>> How many non-sse machines are there still out there? How many non-sse2?<br>
><br>
> Hard to tell. Probably <2%, but that's still too much. Some older Athlon XPs<br>
> don't have it for example. And what if someone submits performance<br>
> optimizations (there has been a focus on those recently) to numpy that use<br>
> SSE4 or AVX for example? You don't want to reject those based on the<br>
> limitations of your distribution process.<br>
><br>
>> And how big is the performance boost anyway?<br>
><br>
> Large. For a long time we've put a non-SSE installer for numpy on pypi so<br>
> that people would stop complaining that ``easy_install numpy`` didn't work.<br>
> Then there were regular complaints about dot products being an order of<br>
> magnitude slower than Matlab or R.<br>
<br>
</div>Yes, I wouldn't want that kind of bad PR getting around about<br>
scientific Python "Python is slower than Matlab" etc.<br>
<br>
It seems as if there is a need to extend the pip+wheel+PyPI system<br>
before this can fully work for numpy. I'm sure that the people here<br>
who have been working on all of this would be very interested to know<br>
what kinds of solutions would work best for numpy and related<br>
packages.<br>
<br>
You mentioned in another message that a post-install script seems best<br>
to you. I suspect there is a little reluctance to go this way because<br>
one of the goals of the wheel system is to reduce the situation where<br>
users execute arbitrary code from the internet with admin privileges<br>
e.g. "sudo pip install X" will download and run the setup.py from X<br>
with root privileges. Part of the point about wheels is that they<br>
don't need to be "executed" for installation. I know that post-install<br>
scripts are common in .deb and .rpm packages but I think that the use<br>
case there is slightly different as the files are downloaded from<br>
controlled repositories whereas PyPI has no quality assurance.<br></blockquote><div><br></div><div>I don't think it's avoidable - anything that is transparant to the user will have to execute code. The multiwheel idea of Nick looks good to me.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

BTW, how do the distros handle e.g. SSE?<br></blockquote><div><br></div><div>I don't know exactly to be honest.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My understanding is that they<br>
just strip out all the SSE and related non-portable extensions and<br>
ship generic 686 binaries. My experience is with Ubuntu and I know<br>
they're not very good at handling BLAS with numpy and they don't seem<br>
to be able to compile fftpack as well as Cristoph can.<br>
<br>
Perhaps a good near-term plan might be to<br>
1) Add the bdist_wheel command to numpy - which may actually be almost<br>
automatic with new enough setuptools/pip and wheel installed.<br>
2) Upload wheels for OSX to PyPI - for OSX SSE support can be inferred<br>
from OS version which wheels can currently handle.<br>
3) Upload wheels for Windows to somewhere other than PyPI e.g.<br>
SourceForge pending a distribution solution that can detect SSE<br>
support on Windows.<br></blockquote><div><br></div><div>That's a reasonable plan. I have an OS X wheel already, which required only a minor change to numpy's setup.py.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I think it would be good to have a go at wheels even if they're not<br>
fully ready for PyPI (just in case some other issue surfaces in the<br>
process).<br></blockquote><div><br></div><div>Agreed.<br><br>Ralf<br><br></div></div></div></div>