<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-11 19:19 GMT+02:00 Olivier Grisel <span dir="ltr"><<a href="mailto:olivier.grisel@ensta.org" target="_blank">olivier.grisel@ensta.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">2015-07-10 22:13 GMT+02:00 Carl Kleffner <<a href="mailto:cmkleffner@gmail.com">cmkleffner@gmail.com</a>>:<br>
><br>
><br>
> 2015-07-10 19:06 GMT+02:00 Olivier Grisel <<a href="mailto:olivier.grisel@ensta.org">olivier.grisel@ensta.org</a>>:<br>
>><br>
>> 2015-07-10 16:47 GMT+02:00 Carl Kleffner <<a href="mailto:cmkleffner@gmail.com">cmkleffner@gmail.com</a>>:<br>
>> > Hi Olivier,<br>
>> ><br>
>> > yes, this is all explained in<br>
>> > <a href="https://github.com/xianyi/OpenBLAS/wiki/Faq#choose_target_dynamic" rel="noreferrer" target="_blank">https://github.com/xianyi/OpenBLAS/wiki/Faq#choose_target_dynamic</a> as<br>
>> > well.<br>
>> > This seems to be necessary for CI systems, right?<br>
>><br>
>> The auto detection should work. If not it's a bug and we should find a<br>
>> minimalistic reproduction case to report it to the openblas<br>
>> maintainers.<br>
>><br>
> I have a debug version of libopenblaspy.dll at hand for 32bit architecture,<br>
> 64bit I have to build. I propose to build small testcases with python, as<br>
> @wernsaar, the main developer of the newer OpenBLAS kernels is able to<br>
> handle this.<br>
<br>
</span>Done here, feel free to join the discussion:<br>
<br>
<a href="https://github.com/xianyi/OpenBLAS/issues/603" rel="noreferrer" target="_blank">https://github.com/xianyi/OpenBLAS/issues/603</a><br>
<span class=""><br>
> Debug builds of libopenblaspy.dll can be used as drop in replacement and can<br>
> be used to emit a stack trace as long the segfault is thrown from numpy or<br>
> OpenBLAS code. DrMingw may be able to catch segfaults from either, I havn't<br>
> tried this yet.<br>
><br>
>><br>
>> Or we could choose to build openblas for an old architecture that<br>
>> should work everywhere like nehalem for instance.<br>
<br>
> This is a safe solution.<br>
<br>
</span>Is Nehalem the most common denominator?<br>
<span class=""><br></span></blockquote><div>I think it is PRESCOTT. BTW: For now you could use now OPTERON_SSE3 or OPTERON instead of NEHALEM, as these are AMD kernels without the barcelona assembler part.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Or one could leave out all kernels above<br>
> sandybridge in a dynamic build as long OpenBLAS has errors with newer<br>
> kernels.<br>
<br>
</span>Yes that's an option. How do you do that? I cannot find such a build<br>
option in the documentation.<br>
<span class=""><br></span></blockquote><div>Just patches to be include as an option later on.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> The best technical solution IMHO would be to make an extra mingwpy.openblas<br>
> python package to load libopenblaspy.dll into the process space, as this<br>
> package could be upgraded independant from numpy/scipy. On the other side<br>
> this would mean an additionally package dependancy for numpy at least on the<br>
> windows platform.<br>
<br>
</span>Having a windows only dependency on such a wheel sounds fine with me.<br>
However that would mean to ensure that the dll is properly loaded in<br>
the windows dll search path prior to importing extensions such as<br>
numpy.core._dotblas right? Could this be done via adding something to<br>
`numpy.__init__.py` such as:<br>
<br>
```<br>
if sys.platform == 'win32':<br>
try:<br>
# Ensure that libopenblaspy.dll can be found prior to<br>
# loading numpy.core._dotblas<br>
from mingwpy import openblas<br>
except:<br>
warnings.warn('Failed to load mingwpy's openblas')<br>
<br>
# import numpy.core stuff here<br>
```<br>
<span class=""><br></span></blockquote><div>Or equip numpy and scipy with the DLL as a fallback, if no 'package' for OpenBLAS is installed. With an additional OpenBLAS package you then can augument the numpy OpenBLAS with a newer one.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> <a href="http://anaconda.org" rel="noreferrer" target="_blank">anaconda.org</a> is the new replacement for <a href="http://binstar.org" rel="noreferrer" target="_blank">binstar.org</a> as announced in the<br>
> anaconda ml and should be used right now.<br>
<br>
</span>Ok I did not know.<br>
<span class="im"><br>
--<br>
Olivier<br>
<a href="http://twitter.com/ogrisel" rel="noreferrer" target="_blank">http://twitter.com/ogrisel</a> - <a href="http://github.com/ogrisel" rel="noreferrer" target="_blank">http://github.com/ogrisel</a><br>
</span><div class=""><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>