[Numpy-discussion] Video meeting this week

Carl Kleffner cmkleffner at gmail.com
Sun Jul 12 04:04:33 EDT 2015


2015-07-11 19:19 GMT+02:00 Olivier Grisel <olivier.grisel at ensta.org>:

> 2015-07-10 22:13 GMT+02:00 Carl Kleffner <cmkleffner at gmail.com>:
> >
> >
> > 2015-07-10 19:06 GMT+02:00 Olivier Grisel <olivier.grisel at ensta.org>:
> >>
> >> 2015-07-10 16:47 GMT+02:00 Carl Kleffner <cmkleffner at gmail.com>:
> >> > Hi Olivier,
> >> >
> >> > yes, this is all explained in
> >> > https://github.com/xianyi/OpenBLAS/wiki/Faq#choose_target_dynamic as
> >> > well.
> >> > This seems to be necessary for CI systems, right?
> >>
> >> The auto detection should work. If not it's a bug and we should find a
> >> minimalistic reproduction case to report it to the openblas
> >> maintainers.
> >>
> > I have a debug version of libopenblaspy.dll at hand for 32bit
> architecture,
> > 64bit I have to build. I propose to build small testcases with python, as
> > @wernsaar, the main developer of the newer OpenBLAS kernels is able to
> > handle this.
>
> Done here, feel free to join the discussion:
>
> https://github.com/xianyi/OpenBLAS/issues/603
>
> > Debug builds of libopenblaspy.dll can be used as drop in replacement and
> can
> > be used to emit a stack trace as long the segfault is thrown from numpy
> or
> > OpenBLAS code. DrMingw may be able to catch segfaults from either, I
> havn't
> > tried this yet.
> >
> >>
> >> Or we could choose to build openblas for an old architecture that
> >> should work everywhere like nehalem for instance.
>
> > This is a safe solution.
>
> Is Nehalem the most common denominator?
>
> 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.


> > Or one could leave out all kernels above
> > sandybridge in a dynamic build as long OpenBLAS has errors with newer
> > kernels.
>
> Yes that's an option. How do you do that? I cannot find such a build
> option in the documentation.
>
> Just patches to be include as an option later on.


> > The best technical solution IMHO would be to make an extra
> mingwpy.openblas
> > python package to load libopenblaspy.dll into the process space, as this
> > package could be upgraded independant from numpy/scipy. On the other side
> > this would mean an additionally package dependancy for numpy at least on
> the
> > windows platform.
>
> Having a windows only dependency on such a wheel sounds fine with me.
> However that would mean to ensure that the dll is properly loaded in
> the windows dll search path prior to importing extensions such as
> numpy.core._dotblas right? Could this be done via adding something to
> `numpy.__init__.py` such as:
>
> ```
> if sys.platform == 'win32':
>     try:
>         # Ensure that libopenblaspy.dll can be found prior to
>         # loading numpy.core._dotblas
>         from mingwpy import openblas
>     except:
>         warnings.warn('Failed to load mingwpy's openblas')
>
> # import numpy.core stuff here
> ```
>
> 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.


> > anaconda.org is the new replacement for binstar.org as announced in the
> > anaconda ml and should be used right now.
>
> Ok I did not know.
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150712/6652ba1b/attachment.html>


More information about the NumPy-Discussion mailing list