On Dec 12, 2007 3:04 AM, Christopher Barker <[EMAIL PROTECTED]> wrote:
> Fernando Perez wrote:
> > a simple, reasonable solution that is likely to work: ship TWO
> > binaries of Numpy/Scipy each time:
> >
> > 1. {numpy,scipy}-reference: built with the reference blas from netlib,
> > no atlas, period.
> >
> > 2. {}-atlas: built with whatever the developers have at the time,
> > which will likely mean these days a core 2 duo with SSE2 support.
> > What hardware it was built on should be indicated, so people can at
> > least know this fact.
>
> I disagree -- having an atlas version that only works on recent hardware
> is just asking for complaints -- I think the ONLY way to go is for the
> "standard" binary to be universal. Instructions should be provided for
> building other versions, and if third parties want to distribute
> processor-dependent versions, then great, but that's an extra.
>But that's the problem: it is next to impossible to build ATLAS which works on any processor ! At least, it is not supported by ATLAS developers, and the way it suggested did not work for me. > By the way, I've always been confused by static linking of lapack/atlas > -- it seems to me that this kind of thing is on of the best uses of > dynamic linking -- the main binary is processor dependent, and it is > linked, at runtime, with the host's processor specific lib. -- could we > do it that way: > I believe that lapack/blas are dynamically linked by default. But for a portable solution, I don't see any other solution than dynamic loading. The BLAS/LAPACK library would be like a plug-in, loaded at runtime. But this requires some work, and in perticular, doing it in a cross platform way is not trivial > The standard distro includes a universal dynamic lib. > > Folks build processor-specific libs that can be dropped in to replace > the universal one if someone so desires. Asking the users to do is just asking for new a set of problems, IMHO. I used this approach for the rpms on ashigabou repository (they are compiled against netlib blas/lapack, but you can change the used libraries using runtime library path), but that's not portable. What is needed is a true runtime system in numpy which can detect the processor (not too difficult, although doing it for all compilers is not trivial either), load the right library (difficult to do in a cross platform way), and use it accordingly (not too difficult, but requires some work). David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
