2015-01-23 0:23 GMT+01:00 Nathaniel Smith <[email protected]>: > On Thu, Jan 22, 2015 at 9:29 PM, Carl Kleffner <[email protected]> > wrote: > > I took time to create mingw-w64 based wheels of numpy-1.9.1 and > scipy-0.15.1 > > source distributions and put them on > > https://bitbucket.org/carlkl/mingw-w64-for-python/downloads as well as > on > > binstar.org. The test matrix is python-2.7 and 3.4 for both 32bit and > 64bit. > > > > Feedback is welcome. > > > > The wheels can be pip installed with: > > > > pip install -i https://pypi.binstar.org/carlkl/simple numpy > > pip install -i https://pypi.binstar.org/carlkl/simple scipy > > > > Some technical details: the binaries are build upon OpenBLAS as > accelerated > > BLAS/Lapack. OpenBLAS itself is build with dynamic kernels (similar to > MKL) > > and automatic runtime selection depending on the CPU. The minimal > requested > > feature supplied by the CPU is SSE2. SSE1 and non-SSE CPUs are not > supported > > with this builds. This is the default for 64bit binaries anyway. > > According to the steam hardware survey, 99.98% of windows computers > have SSE2. (http://store.steampowered.com/hwsurvey , click on "other > settings" at the bottom). So this is probably OK :-). > > > OpenBLAS is deployed as part of the numpy wheel. That said, the scipy > wheels > > mentioned above are dependant on the installation of the OpenBLAS based > > numpy and won't work i.e. with an installed numpy-MKL. > > This sounds like it probably needs to be fixed before we can recommend > the scipy wheels for anyone? OTOH it might be fine to start > distributing numpy wheels first. >
I very much prefer dynamic linking to numpy\core\libopenblas.dll instead of static linking to avoid bloat. This matters, because libopenblas.dll is a heavy library (around 30Mb for amd64). As a consequence all packages with dynamic linkage to OpenBLAS depend on numpy-openblas. This is not different to scipy-MKL that has a dependancy to numpy-MKL - see C. Gohlke's site. > For the numpy 32bit builds there are 3 failures for special FP value > tests, > > due to a bug in mingw-w64 that is still present. All scipy versions show > up > > 7 failures with some numerical noise, that could be ignored (or corrected > > with relaxed asserts in the test code). > > > > PR's for numpy and scipy are in preparation. The mingw-w64 compiler used > for > > building can be found at > > https://bitbucket.org/carlkl/mingw-w64-for-python/downloads. > > Correct me if I'm wrong, but it looks like there isn't any details on > how exactly the compiler was set up? Which is fine, I know you've been > doing a ton of work on this and it's much appreciated :-). But > eventually I do think a prerequisite for us adopting these as official > builds is that we'll need a text document (or an executable script!) > that walks through all the steps in setting up the toolchain etc., so > that someone starting from scratch could get it all up and running. > Otherwise we run the risk of eventually ending up back where we are > today, with a creaky old mingw binary snapshot that no-one knows how > it works or how to reproduce... > This has to be done and is in preperation, but not ready for consumption right now. Some preliminary information is given here: https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwstatic-2014-11-readme.md > -n > > -- > Nathaniel J. Smith > Postdoctoral researcher - Informatics - University of Edinburgh > http://vorpus.org > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
