[Numpy-discussion] Video meeting this week
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
> > 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:
> > Debug builds of libopenblaspy.dll can be used as drop in replacement and
> > be used to emit a stack trace as long the segfault is thrown from numpy
> > OpenBLAS code. DrMingw may be able to catch segfaults from either, I
> > 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
> > 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
> > 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
> > 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':
> # Ensure that libopenblaspy.dll can be found prior to
> # loading numpy.core._dotblas
> from mingwpy import openblas
> 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.
> http://twitter.com/ogrisel - http://github.com/ogrisel
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion