On Mon, Sep 16, 2013 at 7:19 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > > On Mon, Sep 16, 2013 at 12:12 PM, David Cournapeau <courn...@gmail.com>wrote: > >> >> >> >> On Mon, Sep 16, 2013 at 4:36 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> New summary >>> >>> 1. 32 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC >>> 2. 64 bit windows, python 2.6, 2.7, 3.2, 3.3, compiled with MSVC, >>> linked with MKL >>> >>> These should be good for both windows 7 and window 8. >>> >>> >> Wait, when was it decided to move to MSVC for the official binaries ? >> Especially using ifort/MKL on windows means it will be difficult for other >> projects to produce packages on top of it. >> >> > It hasn't been decided, this is just a modified version of the initial > post. > ok, sorry for the confusion > Why not use MSVC? python.org does. What is the problem with statically > linked MKL? Do other packages need to link to lapack? The windows build > problem has hung around for years. I'm tired of it. > Which build problem ? Being tired of it does not justify a decision in particular, otherwise we fall into the fallacy "there is a problem, therefore we must do something". There are multiple issues: - moving away from gcc 3.x on 32 bits. Those compilers are old, but it works well today. It is an untenable situation in the long term, though. I will look again at building numpy/scipy with mingw-w64 in 32 bits to see if the problems with -static-* are gone or not. - 64 bits support: linked to first point. If the first point is solved, I am relatively confident this one can too. - moving away from Atlas to MKL: this is much more problematic. First, MKL is *huge*. For info, the MKL package we provide @ Enthought is 70 MB zip compressed, and that's for the DLLs. The static version may be even bigger - using ifort for fortran: by doing this, we impose on *every* package downstream to use ifort as well (same for MKL BTW). There is also the issue of a blas/lapack for windows 64 bits. There the situation has changed a lot since I last looked into those issues: cygwin (required by atlas) now supports 64 bits natively, and openblas is relatively well supported. I would certainly be happy to get rid of ATLAS which is a PITA to maintain, and use openblas instead. Other packages *do* need to link into lapack (scikit learn, theano are examples I am aware of). David For Mac there is first the question of OS X versions, (10.5?), 10.6, 10.7, >>> 10.8. If 10.5 is omitted, packages built on 10.6 should be good for 10.7 >>> and 10.8, so >>> >>> 1. OS X 10.6 python 2.6, 2.7, 3.2, 3.3, compiled with native >>> compiler, linked with Accelerate. >>> >>> The main question seems to be distribution and coordination with scipy. >>> I was thinking we would link in MKL statically, which I think should be OK. >>> Christoph does that and it should decouple Numpy from Scipy. It may not be >>> the most efficient way to do things, but it would work. My impression is >>> that if we wanted to distribute a dynamic library then every user would >>> need an MKL license to use it. >>> >>> It would be good to get this settled soon as we can't afford to futz >>> around with this forever waiting to release Numpy 1.8 and Scipy 0.13. >>> >>> > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
