Re: [devel] пакеты для численного счета

[Vladislav Zavjalov <slazav@altlinux.org>]

On Sun, Sep 20, 2020 at 10:00:59PM +0300, Andrey Savchenko wrote:
> On Sun, 20 Sep 2020 21:41:33 +0300 Vladislav Zavjalov wrote:
> > On Sun, Sep 20, 2020 at 07:34:57PM +0300, Vladimir D. Seleznev wrote:
> > > > Не уверен, что я понял все тонкости. Пока мне кажется разумным следующее:
> > > > 
> > > > * Исправить openblas, чтобы с NO_LAPACK=1 он не делал вид, что
> > > >   предоставляет lapack.
> > > >   Если это сложно, то использовать его встроенный lapack +
> > > >   отвязать liblapack от openblas.
> > > > 
> > > > * Может быть, удалить blas + liblapack и использовать только openblas.
> > > 
> > > А какие есть против такого варианта?
> > 
> > А это я и пытаюсь спросить. Я-то не против все упростить как только
> > можно. Но потом окажется, что есть разные тонкости.
> 
> Есть референсные реализации blas и lapack, есть оптимизированные,
> притом оптимизации разные под разные профили нагрузки. Даже
> openblas можно собрать с openmp и threads (оба опционально) и для
> разных типов задач и нагрузки производителность разная будет.
> 
> Ситуацию усложняет то, что кроме рефенернсных функций ряд библиотек
> предоставляет расширения, поэтому они более-менее взаимозаменяемы
> только по стандартному интерфейсу blas/lapack, но не по полному
> набору функций. Например, xblas даёт повышенную точность.
> 
> Ещё не забывайте про cblas и lapacke (реализации на C).
> 
> Atlas уникален тем, что подстраивается под конкретную систему, это
> ведь Automatically Tuned Linear Algebra System. И делает он это
> во время сборки: для каждой функции тестирует разные реализации
> и/или способы сборки и выбирает наиболее быструю. Очевидно, что
> оптимально на сборочнице, не будет оптимально на пользовательских
> машинах. Мало того, в зависимости от нагрузки сборочницы результат
> сборки пакета может оказаться разным, т.к. под высокой и низкой
> нагрузкой могут быть оптимальны разные оптимизации.
> 
> Так что это очень крутая штука, чтоб предоставить удобный способ её
> сборки пользователям для своих систем, но не очень хорошо подходит
> для единой бинарной сборки для всех.
> 
> Я бы предложил собрать всё что можно с openblas и в самом openblas
> включить поддержку как openmp, так и threads, но при этом сохранить
> альтернативные библиотеки для нуждающихся. Так же не исключено, что
> с openblas соберётся не всё.

Да, я примерно так и понял, и про Atlas, и про openblas.

Я пока не очень разобрался со сборкой openblas, кажется она сейчас без openmp
и даже без threads. Еще, кажется, если собрать его с threads,
то это может вызвать проблемы в многопоточных клиентах. Пишут, что
надо явно тогда ставить OPENBLAS_NUM_THREADS=1. То есть, включив
поддержку threads можно сломать что-нибудь.

Про альтернативные реализации - "референсные" blas и lapack,
наверное, можно сохранить, для опытов. xblas у нас тоже есть.
Есть scalapack, который свой blas тоже с собой носит. И EML для Эльбруса.

Надо бы, наверное, про все это хозяйство какое-то описание иметь (страницу на вики?)