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

[Andrey Savchenko <bircoph@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5508 bytes --]

On Sun, 20 Sep 2020 23:25:23 +0300 Vladislav Zavjalov wrote:
> 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 для Эльбруса.

Про EML есть страничка на intranet, можете посмотреть. Blas
и lapack там, вроде как, полные, но я не пробовал ещё с ними
собирать, пока что только в упаковке самого EML порядок навёл. В EML
ещё есть fftw — но он урезанный, под определённые задачи только
подойдёт.

Там есть ещё куча всего оптимизированного, но интерфейсы
нестандартыные.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]