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

List:       gentoo-dev
Subject:    Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching
From:       Benda Xu <heroxbd () gentoo ! org>
Date:       2019-05-30 4:06:42
Message-ID: 871s0gegbx.fsf () gentoo ! org
[Download RAW message or body]

Hi David,

David Seifert <soap@gentoo.org> writes:

>> > An actual ABI compliance test, e.g. done using abi-compliance-
>> > checker would be more interesting.
>> 
>> As said above, the symbols don't need to be 1-1 copy of each other.
>> Any library which is a superset of the reference one will work.
>
> Again, I'm willing to accept this under a USE="lapack_targets_virtual"
> configuration, 

I hear you, and I was with the same opinion, too.

Nevertheless, if a runtime switch works, it is simpler than USE_EXPAND.

We already have a couple of them, PYTHON_TARGET, RUBY_TARGET, etc.  I
don't want to add more to this list unless absolutely necessary.

Alternatively, it could be exclusive USE flags instead of USE_EXPAND.
That's possible and we need to add a lot of USE flags, OpenBLAS, blis,
reference, altas, nvBLAS, etc.  I don't think it a clean solution.

> but wholesale editing of DT_NEEDED entries is definitely too scary and
> too invasive for most non-sci/hpc users of Gentoo.

Sorry if I confused you.  There is no hack of DT_NEEDED involved.

An application is compiled against the reference, then it is pointed by
LDPATH and ld.so.conf to a drop-in replacement library, and it profits.
That's not more than upgrading a dynamic library.

The scheme was shown to work with gcc runtime, libstdc++, and opengl, in
Gentoo.

> Again, for 99% of users, OpenBLAS will be the right trade-off between
> performance and customizability. Every recompilation of libreoffice or
> chromium will devour more CPU cycles than switching between USE-flag
> implementations.

I understand your point.  Let me elaborate:

1. OpenBLAS has quite a bit of hand-tuned assembly, it is not very
   portable.  Special care is need to manage the default BLAS on
   profiles, like ppc64, arm64, arm, riscv, etc.

2. All the Gentoo users care about optimization.  And there are
   non-science applications that call linear algebra routines.

3. Maintaining different BLAS frameworks in repo/gentoo.git and
   proj/sci.git wastes everybody's time, and causes endless confusion to
   users.  That offsets the time saved to make OpenBLAS the global
   default.

Therefore, from the users' point of view, I still think runtime
switching makes more sense.

Yours,
Benda

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