On Fri, Dec 6, 2013 at 12:44 PM, Donald Stufft <donald@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 <ncoghlan@gmail.com> wrote:
On Fri, Dec 6, 2013 at 6:47 AM, Nick Coghlan <ncoghlan@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
a fundamentally wrong approach. And in order to not litter the source
On 6 December 2013 17:21, Ralf Gommers <ralf.gommers@gmail.com> wrote: like 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 | ncoghlan@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