<br><br><div class="gmail_quote">On Sat, Aug 4, 2012 at 2:36 PM, David Cournapeau <span dir="ltr"><<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Aug 4, 2012 at 12:14 PM, Aron Ahmadia <<a href="mailto:aron@ahmadia.net">aron@ahmadia.net</a>> wrote:<br>
> Hi David,<br>
><br>
> Apple's response here is somewhat confusing, but I will add that on the<br>
> supercomputing side of things we rarely fork, as this is not well-supported<br>
> from the vendors or the hardware (it's hard enough to performantly spawn<br>
> 500,000 processes statically, doing this dynamically becomes even more<br>
> challenging).  This sounds like an issue in Python multiprocessing itself,<br>
> as I guess many other Apple libraries will fail or crash with the<br>
> fork-no-exec model.<br>
><br>
> My suggestion would be that numpy continue to integrate with Accelerate but<br>
> prefer a macports or brew supplied blas, if available.  This should probably<br>
> also be filed as a wont-fix bug on the tracker so anybody who hits the same<br>
> problem knows that it's on the system side and not us.<br>
<br>
</div>To be clear, I am not suggesting removing support for linking against<br>
accelerate, just to go away from it for our binary releases.</blockquote><div><br>Would there be any issues when mixing for example a numpy built against ATLAS with a scipy built against Accelerate? <br><br>Ralf<br><br></div>
</div>