On Fri, Dec 6, 2013 at 12:44 PM, Donald Stufft <don...@stufft.io> wrote:
> How does conda handle SSE vs SSE2 vs SSE3? I’m digging through it’s > source code and just installed numpy with it and I can’t seem to find any > handling of that? > I can't speak for conda, but @enthought, we solve it by using the MKL, which selects the right implementation at runtime. Linux distributions have system to cope with it (the hwcap capabtility of ld), but even there few packages use it. Atlas, libc are the ones I am aware of. And this breaks anyway when you use static linking obviously. David > > On Dec 6, 2013, at 7:33 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > On 6 December 2013 17:21, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > >> On Fri, Dec 6, 2013 at 6:47 AM, Nick Coghlan <ncogh...@gmail.com> > wrote: > >>> With that approach, the existing wheel model would work (no need for a > >>> variant system), and numpy installations could be freely moved between > >>> machines (or shared via a network directory). > >> > >> Hmm, taking a compile flag and encoding it in the package layout seems > like > >> a fundamentally wrong approach. And in order to not litter the source > tree > >> and all installs with lots of empty dirs, the changes to __init__.py > will > >> have to be made at build time based on whether you're building Windows > >> binaries or something else. Path manipulation is usually fragile as > well. So > >> I suspect this is not going to fly. > > > > In the absence of the perfect solution (i.e. picking the right variant > > out of no SSE, SSE2, SSE3 automatically), would it be a reasonable > > compromise to standardise on SSE2 as "lowest acceptable common > > denominator"? > > > > Users with no sse capability at all or that wanted to take advantage > > of the SSE3 optimisations, would need to grab one of the Windows > > installers or something from conda, but for a lot of users, a "pip > > install numpy" that dropped the SSE2 version onto their system would > > be just fine, and a much lower barrier to entry than "well, first > > install this other packaging system that doesn't interoperate with > > your OS package manager at all...". > > > > Are we letting perfect be the enemy of better, here? (punting on the > > question for 6 months and seeing if we can deal with the install-time > > variant problem in pip 1.6 is certainly an option, but if we don't > > *need* to wait that long...) > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
