2015-07-11 19:19 GMT+02:00 Olivier Grisel <olivier.gri...@ensta.org>:
> 2015-07-10 22:13 GMT+02:00 Carl Kleffner <cmkleff...@gmail.com>: > > > > > > 2015-07-10 19:06 GMT+02:00 Olivier Grisel <olivier.gri...@ensta.org>: > >> > >> 2015-07-10 16:47 GMT+02:00 Carl Kleffner <cmkleff...@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
