[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    Re: [opensuse-packaging] Intel MKL packaging
From:       Todd Rme <toddrme2178 () gmail ! com>
Date:       2017-05-08 15:57:28
Message-ID: CADb7s=uKMBqKL4ShcG5GfQ029g=5kqsX4fqWJut=3VeQd9Lk5w () mail ! gmail ! com
[Download RAW message or body]

On Mon, May 8, 2017 at 11:36 AM, Xing <stecue@gmail.com> wrote:
> On 05/08/2017 11:15 AM, Todd Rme wrote:
>>
>> On Mon, May 8, 2017 at 11:01 AM, Xing <stecue@gmail.com> wrote:
>>>
>>> On 05/07/2017 03:22 PM, auxsvr wrote:
>>>>
>>>> Hi,
>>>>
>>>> There are several options to licence Intel MKL (free or community
>>>> licence)
>>>> , which makes including it in the OBS easier. If this is not allowed,
>>>> what
>>>> is the best way to package packages depending on it, e.g. numpy or
>>>> pytorch?
>>>
>>> The current numpy/scipy requires openblas. But I think it might be better
>>> to
>>> compile numpy/scipy against the standard "unoptimized" lapack/blas and
>>> the
>>> uses can switch to other optimized lapack/blas such as openblas/mkl at
>>> runtime using "update-alternatives"?
>>>
>>> Sincerely yours
>>> Xing
>>
>> We can't support MKL using update-alternatives because it isn't
>> open-source. The rules of OBS forbid us from distributing it. So there
>> are really only two choices, an unoptimized version using lapack and
>> an optimized version using openblas.  I don't see an advantage to
>> shipping the unoptimized version.
>
> It might be simpler for users to use MKL if numpy is built against
> lapack/blas. A user just need to install MKL and add MKL to the libblas.so.3
> and liblapack.so.3 groups.
>
> Also, openblas itself has 3 different flavors and it seems that numpy is
> linked to libopenblas_pthreads.so.0 and it cannot be changed using
> "update-alternatives" because only "libopenblas.so.0" can be configured by
> "update-alternatives" by default.
>
> If we want to ship an optimized numpy , is it them same if we build numpy
> against lapack/blas and put a "Requires: openblas" in the .spec file?
> Installing openblas itself will update the links to the libblas.so.3 and
> liblapack.so.3, right?

That depends on whether there are compile-time optimizations.
Considering that numpy has a compile-time switch for the library you
want to build against rather than just using whatever is available and
changing at runtime, and that specific changes needed to be made to
numpy to support openblas, I would think that runtime switching is
different than choosing a target at compile time.
-- 
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]