<br><br><div class="gmail_quote">On Sat, Aug 4, 2012 at 2:36 PM, David Cournapeau <span dir="ltr">&lt;<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>&gt;</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 &lt;<a href="mailto:aron@ahmadia.net">aron@ahmadia.net</a>&gt; wrote:<br>
&gt; Hi David,<br>
&gt;<br>
&gt; Apple&#39;s response here is somewhat confusing, but I will add that on the<br>
&gt; supercomputing side of things we rarely fork, as this is not well-supported<br>
&gt; from the vendors or the hardware (it&#39;s hard enough to performantly spawn<br>
&gt; 500,000 processes statically, doing this dynamically becomes even more<br>
&gt; challenging).  This sounds like an issue in Python multiprocessing itself,<br>
&gt; as I guess many other Apple libraries will fail or crash with the<br>
&gt; fork-no-exec model.<br>
&gt;<br>
&gt; My suggestion would be that numpy continue to integrate with Accelerate but<br>
&gt; prefer a macports or brew supplied blas, if available.  This should probably<br>
&gt; also be filed as a wont-fix bug on the tracker so anybody who hits the same<br>
&gt; problem knows that it&#39;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>