[Numpy-discussion] Video meeting this week

[Olivier Grisel]

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?

> 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.

> 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
```

> 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