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

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

[Vladislav Zavjalov]

Привет!

Я немного поразбирал наследие @real, библиотеки для численного счета.
Почти все они уже вылетели из Сизифа. Я не слишком большой специалист, и
точно не планирую ничего собирать для вычислительных кластеров. Мой
интерес был посмотреть разные варианты для счета нетяжелых
задач на домашнем компьютере: dealii (с ней я когда-то вполне успешно
работал), gmsh+getdp и т.п. Хочется собрать все в простой конфигурации,
выкинув излишнее. Буду рад замечаниям и предложениям.

Пока увидел следующее:

* atlas
  https://packages.altlinux.org/ru/sisyphus/srpms/atlas
  http://math-atlas.sourceforge.net/

  Наша версия 3.9.35 (4.2011), cобрана только для i586 и x86_64.
  Aпстримная стабильная версия - 3.10.3 (7.2016)

  В принципе, это Blas + часть Lapack, должно заменяться libopenblas,
  но у меня с этим были проблемы и при сборке getdb и при сборке gmsh.
  Я пока обошелся существующей libatlas, поставив ExclusiveArch,
  но, наверное, надо обновить, попробовать собрать и под другие
  архитектуры...


* petsc
  https://packages.altlinux.org/ru/c8_1/srpms/petsc-real
  https://packages.altlinux.org/ru/c8_1/srpms/petsc-complex
  https://www.mcs.anl.gov/petsc/

  Наша последняя версия 3.5.4 (5.2015), из Сизифа вылетела
  Апстримная - 3.13.5 (3.2020)

  У меня получилось собрать новую версию, примерно с такой же
  упаковкой как раньше, с вариантами -real и -complex, в специально
  отведенных местах.

  С другой стороны, понял, что для домашнего использования она
  мне, скорее всего, не пригодится, т.к. заменяется древней
  библиотекой libsparskit. Так что в Сизиф не отправлял.


* slepc
  https://packages.altlinux.org/ru/c8_1/srpms/slepc-real
  https://packages.altlinux.org/ru/c8_1/srpms/slepc-complex
  https://slepc.upv.es/

  Наша версия: 3.5.4 (5.2015), из Сизифа вылетела
  Апстрим: 3.13.4 (2.2020)

  Кажется, имеет смысл только в связке с petsc, сборку пока
  толком не смотрел.


* libmesh
  https://packages.altlinux.org/ru/c8_1/srpms/libmesh-real
  https://packages.altlinux.org/ru/c8_1/srpms/libmesh-real
  http://libmesh.github.io/

  Наша версия: 1.0.0 (7.2014), из Сизифа вылетела
  Апстрим: 1.5.1 (11.2019)

  Была собрана с petsc и slepc, в вариантах -real и -complex.
  Собираюсь собрать в простeйшей конфигурации и посмотреть,
  нужна ли она мне.


* gmsh
  https://packages.altlinux.org/ru/c8_1/srpms/gmsh
  URL: https://gmsh.info/

  Наша последняя версия 2.8.5 (7.2014), из Сизифа вылетела
  Апстримная - 4.6.0 (6.2020)

  Собрал новую версию в Сизиф (только i586 и x86_64 из-за libatlas),
  проверил, что работает.


* getdp -- раньше в Сизифе не было

  Собрал последнюю версию в Сизиф (только i586 и x86_64 из-за libatlas),
  с поддержкой gmsh, проверил, что работает.


* dealii
  https://packages.altlinux.org/ru/c7_1/srpms/dealii-real
  https://packages.altlinux.org/ru/c7_1/srpms/dealii-complex
  https://www.dealii.org/

  Наша последняя версия: 7.3 (2.2013), из Сизифа вылетела
  Апстрим: 9.2.0 (5.2020)

  Я с ней работал 7 лет назад, мне она нравилась. Немного чудовищна,
  экспортирует больше 150 тысяч символов, с отладочной информацией
  занимает 1Gb, из-за этого при сборке застревает в узких местах.

  У @real собиралась с petsc, openmpi и т.п., в двух версиях (real и complex),
  ставилась в директории petsc (%_libdir/petsc-{real,complex}), ничего наружу
  не экспортировала (и в те времена я так и не разобрался с этой установкой,
  собирал все себе локально).

  У меня получилось собрать новую версию без лишних зависимостей, так что мои старые
  программы собрались и заработали, пропихнуть в Сизиф не получилось, но все rpm'ы
  есть тут: http://git.altlinux.org/tasks/257979/ .
  Думаю, что ее можно, как и раньше, запаковать в какой-то нестандартный угол,
  ничего не экспортируя (поскольку эта библиотека предназначена скорее для
  написания своих локальных программ, чем для сборки других пакетов).


Резюме: libatlas - пока обхожусь старым, попробую обновить, как руки
дойдут. petsc+slepc - мне пока не очень интересно, если кому-то нужно -
могу поделиться простой сборкой нового petsc. libmesh - пока не смотрел, но
собираюсь. gmsh, getdp - собраны в Сизиф, работают. dealii -
собрано, работает, но пока не понял, надо ли отправлять в Сизиф и как
лучше запаковать.

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

[Vladislav Zavjalov]

Еще поразбирался с Blas/Lapack. Это старые-добрые фортрановские библиотеки
"Basic Linear Algebra Subroutines" и "Linear Algebra PACKage" -
работа с матрицами, и решение систем линейных уравнений. Lapack использует Blas.

У нас сейчас есть следующее:

* blas -- "стандартный" blas.
  http://www.netlib.org/blas/

* liblapack -- "стандартный" lapack. У нас собран с openblas.
  http://www.netlib.org/lapack/

* openblas -- Оптимизированная версия Blas, с поддержкой
  многопоточных вычислений и т.п.
  https://github.com/xianyi/OpenBLAS

  Openblas может и сам предоставлять стандартный lapack, но у нас он собран с ключом
  NO_LAPACK=1. При этом в заголовочные файлы функции из lapack попадают, а
  в библиотеку - нет. В результате, при сборке разных программ возникают
  проблемы на этапе линковки, даже если liblapack-devel есть в системе.
  Приходится вручную указывать, что линковаться надо с libopenblas + liblapack.

* libatlas -- Оптимизированный blas + небольшая часть lapack.
  http://math-atlas.sourceforge.net/

  У нас очень старая версия, собирается только под i586 и x86_64.
  Это довольно странная библиотека, и я не уверен, что
  ее следует держать в репозитории. Дело в том, что она оптимизирует функции из
  blas/lapack под конкретный процессор - на этапе сборки. Не очень понятно,
  имеют ли эти оптимизации смысл при распространении в виде бинарных пакетов.
  Например, явно написано, что оптимизации будут бессмысленны при включенном
  CPU throttling и лучше тогда использовать обычный blas.
  Как сделать "правильную" сборку - не очень понятно.


Не уверен, что я понял все тонкости. Пока мне кажется разумным следующее:

* Исправить openblas, чтобы с NO_LAPACK=1 он не делал вид, что
  предоставляет lapack.
  Если это сложно, то использовать его встроенный lapack +
  отвязать liblapack от openblas.

* Может быть, удалить blas + liblapack и использовать только openblas.

* Удалить libatlas, пересобрав клиентов с openblas.

Еще бы понять, какие клиенты используют эти библиотеки...

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

[Vladimir D. Seleznev]

> Не уверен, что я понял все тонкости. Пока мне кажется разумным следующее:
> 
> * Исправить openblas, чтобы с NO_LAPACK=1 он не делал вид, что
>   предоставляет lapack.
>   Если это сложно, то использовать его встроенный lapack +
>   отвязать liblapack от openblas.
> 
> * Может быть, удалить blas + liblapack и использовать только openblas.

А какие есть против такого варианта?

> * Удалить libatlas, пересобрав клиентов с openblas.
> 
> Еще бы понять, какие клиенты используют эти библиотеки...

Клиенты libatlas:

* libarpack-ng

Клиенты liblapack:

* getdp
* getfemxx
* gmsh
* harminv
* hypre
* itpp
* lapack
* lapackpp
* libarpack-ng
* libcf-mpi
* libflame
* liblevmar
* libscalapack
* libslatec
* libsuitesparse
* mpb
* ngsolve
* octave
* octave-control
* octave-ltfat
* octave-optim
* octave-optiminterp
* parms
* primme
* python3-module-numpy
* python3-module-scipy
* python-module-cvxopt
* python-module-numpy
* python-module-pysparse
* python-module-scipy
* qm-vamp-plugins
* qrupdate
* R-base
* spai
* superlu4.0
* taucs
* yaafe

Клиенты blas:

<нет>

Клиенты openblas:

* blzpack
* clapack
* getfemxx
* gmsh
* harminv
* hlzpack
* hypre
* icfs
* lapack
* lapackpp
* libflame
* liblinpack
* libscalapack
* libsuitesparse
* mpb
* mumps
* ngsolve
* octave
* octave-control
* octave-ltfat
* octave-nan
* opentoonz
* parms
* primme
* python3-module-numpy
* python3-module-scipy
* python-module-cvxopt
* python-module-nlpy
* python-module-numpy
* python-module-pysparse
* python-module-scipy
* qm-dsp
* qrupdate
* R-base
* skypack
* sparskit
* superlu4.0
* superlu_dist
* taucs

Т.е., с libatlas собран только один клиент, всё остальное собрано с
openblas, который использует liblapack.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Vladislav Zavjalov]

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.
> 
> А какие есть против такого варианта?

А это я и пытаюсь спросить. Я-то не против все упростить как только
можно. Но потом окажется, что есть разные тонкости.

> > Еще бы понять, какие клиенты используют эти библиотеки...
> 
> Клиенты libatlas:
>-
> * libarpack-ng

Спасибо за списки! libarpack - это нужная вещь, попробую
пересобрать. С ней собран, например, octave, он у меня
и втаскивает libatlas в систему.

Остальное, получается, собрано правильно. Хотя с openblas надо бы
что-то сделать. Сейчас и configure и cmake уверены, что lapack находится
в нем, и вылетают на линковке, если делать сборку в дефолтной конфигурации.
Это исправляется явным указанием, что надо линковаться еще и с liblapack,
но хочется и дефолтное поведение сделать рабочим.

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

[Vladislav Zavjalov]

On Sun, Sep 20, 2020 at 09:41:33PM +0300, Vladislav Zavjalov wrote:
> > > Еще бы понять, какие клиенты используют эти библиотеки...
> > 
> > Клиенты libatlas:
> >-
> > * libarpack-ng
> 
> Спасибо за списки!

А можно ли попросить такие же списки для libarpack-ng и libarpack ?

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

[Vladimir D. Seleznev]

On Sun, Sep 20, 2020 at 09:53:34PM +0300, Vladislav Zavjalov wrote:
> On Sun, Sep 20, 2020 at 09:41:33PM +0300, Vladislav Zavjalov wrote:
> > > > Еще бы понять, какие клиенты используют эти библиотеки...
> > > 
> > > Клиенты libatlas:
> > >-
> > > * libarpack-ng
> > 
> > Спасибо за списки!
> 
> А можно ли попросить такие же списки для libarpack-ng и libarpack ?

Для libarpack-ng:

* getdp
* libarpack-ng
* octave

А что такое libarpack?

Самый простой способ получить список зависимостей для текущего состояния
репозитория — через apt-get whatdepends. Узнать, какому пакету
соответствует бинарный пакет — с помошью pkglist-query по
/var/lib/apt/lists/*.{classic,...}.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Vladislav Zavjalov]

On Mon, Sep 21, 2020 at 12:47:32AM +0300, Vladimir D. Seleznev wrote:
> > А можно ли попросить такие же списки для libarpack-ng и libarpack ?
> 
> Для libarpack-ng:
> 
> * getdp
> * libarpack-ng
> * octave
> 
> А что такое libarpack?

Подпакет вот этого:
https://packages.altlinux.org/ru/sisyphus/srpms/arpack

> Самый простой способ получить список зависимостей для текущего состояния
> репозитория ??? через apt-get whatdepends. Узнать, какому пакету
> соответствует бинарный пакет ??? с помошью pkglist-query по
> /var/lib/apt/lists/*.{classic,...}.

О, нашел, apt-cache whatdepends. Спасибо, буду применять.
Похоже, что у arpack нет клиентов, все у libarpack-ng.

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

[Vitaly Lipatov]

Vladimir D. Seleznev писал 21.9.20 0:47:
...
> Самый простой способ получить список зависимостей для текущего 
> состояния
> репозитория — через apt-get whatdepends. Узнать, какому пакету
> соответствует бинарный пакет — с помошью pkglist-query по
> /var/lib/apt/lists/*.{classic,...}.
А нельзя ли подробнее?
$ pkglist-query '%{name}-%{version}-%{release}.src.rpm\n' 
/var/lib/apt/lists/*.classic | wc -l
46796

Как узнать соответствие бинарного пакета и src.rpm?

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[Vladimir D. Seleznev]

On Mon, Sep 21, 2020 at 10:54:32PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 21.9.20 0:47:
> ...
> > Самый простой способ получить список зависимостей для текущего 
> > состояния
> > репозитория — через apt-get whatdepends. Узнать, какому пакету
> > соответствует бинарный пакет — с помошью pkglist-query по
> > /var/lib/apt/lists/*.{classic,...}.
> А нельзя ли подробнее?
> $ pkglist-query '%{name}-%{version}-%{release}.src.rpm\n' 
> /var/lib/apt/lists/*.classic | wc -l
> 46796
> 
> Как узнать соответствие бинарного пакета и src.rpm?

Например, так:

pkglist-query '%{name} %{sourcerpm}\n'

И поджойнить вывод со списком бинарных пакетов.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Anton Farygin]

On 21.09.2020 23:10, Vladimir D. Seleznev wrote:
> On Mon, Sep 21, 2020 at 10:54:32PM +0300, Vitaly Lipatov wrote:
>> Vladimir D. Seleznev писал 21.9.20 0:47:
>> ...
>>> Самый простой способ получить список зависимостей для текущего
>>> состояния
>>> репозитория — через apt-get whatdepends. Узнать, какому пакету
>>> соответствует бинарный пакет — с помошью pkglist-query по
>>> /var/lib/apt/lists/*.{classic,...}.
>> А нельзя ли подробнее?
>> $ pkglist-query '%{name}-%{version}-%{release}.src.rpm\n'
>> /var/lib/apt/lists/*.classic | wc -l
>> 46796
>>
>> Как узнать соответствие бинарного пакета и src.rpm?
> Например, так:
>
> pkglist-query '%{name} %{sourcerpm}\n'
>
> И поджойнить вывод со списком бинарных пакетов.
>
Для облегчения труда у нас есть такой экспериментальный интерфейс:
curl -s -k 
"https://repodb.basealt.space/what_depends_src?name=ocaml&dptype=both&branch=sisyphus"|jq 
-r '.[].name'

он покажет какие исходные пакеты зависят по сборке и runtime от 
исходного пакета ocaml (точнее от того, что из него собирается).

Вернёт отсортированное в порядке сборки.

https://repodb.basealt.space/what_depends_src?name=ocaml&dptype=binary&branch=sisyphus 
- это только runtime зависимости

https://repodb.basealt.space/what_depends_src?name=ocaml&dptype=source&branch=sisyphus 
- это зависимости исходных пакетов.


Интерфейс экспериментальный, уже есть планы на его рефакторинг. Но 
пользоваться можно.

База обновляется раз в сутки около 10 утра по москве.

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

[Igor Vlasenko]

On Mon, Sep 21, 2020 at 10:54:32PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 21.9.20 0:47:
> ...
> > Самый простой способ получить список зависимостей для текущего состояния
> > репозитория — через apt-get whatdepends. Узнать, какому пакету
> > соответствует бинарный пакет — с помошью pkglist-query по
> > /var/lib/apt/lists/*.{classic,...}.
> А нельзя ли подробнее?
> $ pkglist-query '%{name}-%{version}-%{release}.src.rpm\n'
> /var/lib/apt/lists/*.classic | wc -l
> 46796
> 
> Как узнать соответствие бинарного пакета и src.rpm?

Есть еще altlinux-repolist-utils

утилиты
altlinux-repolist-src-files-to-bin-files
altlinux-repolist-src-files-to-bin-names
altlinux-repolist-src-files-to-src-names
altlinux-repolist-src-names-to-bin-files
altlinux-repolist-src-names-to-bin-names
altlinux-repolist-src-names-to-src-files

свежий в task
#258522 altlinux-repolist-utils.git=0.007-alt1

-- 

I V

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

[Andrey Savchenko]

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

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 соберётся не всё.

> > > Еще бы понять, какие клиенты используют эти библиотеки...
> > 
> > Клиенты libatlas:
> >-
> > * libarpack-ng
> 
> Спасибо за списки! libarpack - это нужная вещь, попробую
> пересобрать. С ней собран, например, octave, он у меня
> и втаскивает libatlas в систему.
> 
> Остальное, получается, собрано правильно. Хотя с openblas надо бы
> что-то сделать. Сейчас и configure и cmake уверены, что lapack находится
> в нем, и вылетают на линковке, если делать сборку в дефолтной конфигурации.
> Это исправляется явным указанием, что надо линковаться еще и с liblapack,
> но хочется и дефолтное поведение сделать рабочим.
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Best regards,
Andrew Savchenko

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

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

[Vladislav Zavjalov]

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 для Эльбруса.

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

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

[Andrey Savchenko]

[-- 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 --]

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

[Vladimir D. Seleznev]

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.
> 
> А какие есть против такого варианта?
> 
> > * Удалить libatlas, пересобрав клиентов с openblas.
> > 
> > Еще бы понять, какие клиенты используют эти библиотеки...
> 
> Клиенты libatlas:
> 
> * libarpack-ng
> 
> Клиенты liblapack:
> 
> * getdp
> * getfemxx
> * gmsh
> * harminv
> * hypre
> * itpp
> * lapack
> * lapackpp
> * libarpack-ng
> * libcf-mpi
> * libflame
> * liblevmar
> * libscalapack
> * libslatec
> * libsuitesparse
> * mpb
> * ngsolve
> * octave
> * octave-control
> * octave-ltfat
> * octave-optim
> * octave-optiminterp
> * parms
> * primme
> * python3-module-numpy
> * python3-module-scipy
> * python-module-cvxopt
> * python-module-numpy
> * python-module-pysparse
> * python-module-scipy
> * qm-vamp-plugins
> * qrupdate
> * R-base
> * spai
> * superlu4.0
> * taucs
> * yaafe
> 
> Клиенты blas:
> 
> <нет>
> 
> Клиенты openblas:
> 
> * blzpack
> * clapack
> * getfemxx
> * gmsh
> * harminv
> * hlzpack
> * hypre
> * icfs
> * lapack
> * lapackpp
> * libflame
> * liblinpack
> * libscalapack
> * libsuitesparse
> * mpb
> * mumps
> * ngsolve
> * octave
> * octave-control
> * octave-ltfat
> * octave-nan
> * opentoonz
> * parms
> * primme
> * python3-module-numpy
> * python3-module-scipy
> * python-module-cvxopt
> * python-module-nlpy
> * python-module-numpy
> * python-module-pysparse
> * python-module-scipy
> * qm-dsp
> * qrupdate
> * R-base
> * skypack
> * sparskit
> * superlu4.0
> * superlu_dist
> * taucs
> 
> Т.е., с libatlas собран только один клиент, всё остальное собрано с
> openblas, который использует liblapack.

Уточнение: это списки для текущего состояния репозитория для x86_64.
Для полноты картины их надо объединить с такими же списками для других
архитектур.

-- 
   WBR,
   Vladimir D. Seleznev

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

[Ivan A. Melnikov]

On Sun, Sep 20, 2020 at 04:28:14PM +0300, Vladislav Zavjalov wrote:
> Еще поразбирался с Blas/Lapack. Это старые-добрые фортрановские библиотеки
> "Basic Linear Algebra Subroutines" и "Linear Algebra PACKage" -
> работа с матрицами, и решение систем линейных уравнений. Lapack использует Blas.
> 
> У нас сейчас есть следующее:
> 
> * blas -- "стандартный" blas.
>   http://www.netlib.org/blas/
> 
> * liblapack -- "стандартный" lapack. У нас собран с openblas.
>   http://www.netlib.org/lapack/
> 
> * openblas -- Оптимизированная версия Blas, с поддержкой
>   многопоточных вычислений и т.п.
>   https://github.com/xianyi/OpenBLAS
> 
>   Openblas может и сам предоставлять стандартный lapack, но у нас он собран с ключом
>   NO_LAPACK=1. При этом в заголовочные файлы функции из lapack попадают, а
>   в библиотеку - нет. В результате, при сборке разных программ возникают
>   проблемы на этапе линковки, даже если liblapack-devel есть в системе.
>   Приходится вручную указывать, что линковаться надо с libopenblas + liblapack.
> 
> * libatlas -- Оптимизированный blas + небольшая часть lapack.
>   http://math-atlas.sourceforge.net/
> 
>   У нас очень старая версия, собирается только под i586 и x86_64.
>   Это довольно странная библиотека, и я не уверен, что
>   ее следует держать в репозитории. Дело в том, что она оптимизирует функции из
>   blas/lapack под конкретный процессор - на этапе сборки.

Насколько я понял, она может при сборке погонять бенчмарки
в процессе сборки, и выбрать варианты релизации, лучше подходящие
для конкретного железа, но при сборке именно пакета этого не делается,
а используются готовые профили, оптимизированные под некое обобщённое
непонятно что.

>   Не очень понятно,
>   имеют ли эти оптимизации смысл при распространении в виде бинарных пакетов.
>   Например, явно написано, что оптимизации будут бессмысленны при включенном
>   CPU throttling и лучше тогда использовать обычный blas.
>   Как сделать "правильную" сборку - не очень понятно.
> 
> 
> Не уверен, что я понял все тонкости. Пока мне кажется разумным следующее:
> 
> * Исправить openblas, чтобы с NO_LAPACK=1 он не делал вид, что
>   предоставляет lapack.
>   Если это сложно, то использовать его встроенный lapack +
>   отвязать liblapack от openblas.
> 
> * Может быть, удалить blas + liblapack и использовать только openblas.

openblas традиционно не умеет mipsel, и, кажется, riscv.
Под mipsel её собрать вроде бы можно парой нехитрых патчей,
но я что-то не решился, так как непонятны критерии
работоспособности, приемлимости и всего такого.

С другой стороны, идея одного дистрибутивного blas и lapack
выглядит очень привлекательной.

> * Удалить libatlas, пересобрав клиентов с openblas.
> 
> Еще бы понять, какие клиенты используют эти библиотеки...
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Vladislav Zavjalov]

On Mon, Sep 21, 2020 at 01:49:44PM +0400, Ivan A. Melnikov wrote:
> > 
> > * Исправить openblas, чтобы с NO_LAPACK=1 он не делал вид, что
> >   предоставляет lapack.
> >   Если это сложно, то использовать его встроенный lapack +
> >   отвязать liblapack от openblas.
> > 
> > * Может быть, удалить blas + liblapack и использовать только openblas.
> 
> openblas традиционно не умеет mipsel, и, кажется, riscv.
> Под mipsel её собрать вроде бы можно парой нехитрых патчей,
> но я что-то не решился, так как непонятны критерии
> работоспособности, приемлимости и всего такого.

Ага, я уже вышел на @arei, который собирал blas как раз
для sisyphus-riscv64.

> С другой стороны, идея одного дистрибутивного blas и lapack
> выглядит очень привлекательной.

Наверное, ничего плохого нет в том, чтобы оставить стандартные
blas+lapack, но рекомендовать всем по возможности собираться
с openblas. Всякое другое (scalapack, xblas) тоже оставить,
на случай, если кому-то надо. Atlas в этом смысле выглядит
наименее полезным в наших условиях, его можно и удалить.

Я пока повесил две ошибки:

https://bugzilla.altlinux.org/38974 -- Или убрать из openblas заголовки
lapack или собрать его со своим lapack (мне второй вариант кажется
хорошим, но он явно более трудоемкий).

https://bugzilla.altlinux.org/38975 -- Пересобрать libarpack-ng с
openblas+liblapack вместо atlas. Таким образом, у libatlas не должно
остаться клиентов.

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

[Anton Farygin]

On 20.09.2020 16:28, Vladislav Zavjalov wrote:
> * openblas -- Оптимизированная версия Blas, с поддержкой
>    многопоточных вычислений и т.п.
>    https://github.com/xianyi/OpenBLAS
>
>    Openblas может и сам предоставлять стандартный lapack, но у нас он собран с ключом
>    NO_LAPACK=1. При этом в заголовочные файлы функции из lapack попадают, а
>    в библиотеку - нет. В результате, при сборке разных программ возникают
>    проблемы на этапе линковки, даже если liblapack-devel есть в системе.
>    Приходится вручную указывать, что линковаться надо с libopenblas + liblapack.

Это, наверное, плохо. Может быть стоит его собрать с внешним lapack ?

+ make -j16 'CFLAGS=-pipe -frecord-gcc-switches -Wall -g -O2 
-I../include -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM 
-DUSEGETTIME' 'LIBS=-L../lib -lsdp'
make: Entering directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
cc -pipe -frecord-gcc-switches -Wall -g -O2 -I../include 
-I/usr/include/openblas -DNOSHORTS -DUSESIGTERM -DUSEGETTIME   -c -o 
csdp.o csdp.c
make: Leaving directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
make: Entering directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
cc -pipe -frecord-gcc-switches -Wall -g -O2 -I../include 
-I/usr/include/openblas -DNOSHORTS -DUSESIGTERM -DUSEGETTIME csdp.o 
-L../lib -lsdp -o csdp
/usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dtrtri_'
/usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dpotrf_'
/usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dpotrs_'
collect2: error: ld returned 1 exit status
make: *** [Makefile:5: csdp] Error 1
make: Leaving directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
error: Bad exit status from /usr/src/tmp/rpm-tmp.39185 (%build)

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

[Vladislav Zavjalov]

On Fri, Sep 25, 2020 at 03:20:56PM +0300, Anton Farygin wrote:
> On 20.09.2020 16:28, Vladislav Zavjalov wrote:
> > * openblas -- Оптимизированная версия Blas, с поддержкой
> >    многопоточных вычислений и т.п.
> >    https://github.com/xianyi/OpenBLAS
> >
> >    Openblas может и сам предоставлять стандартный lapack, но у нас он собран с ключом
> >    NO_LAPACK=1. При этом в заголовочные файлы функции из lapack попадают, а
> >    в библиотеку - нет. В результате, при сборке разных программ возникают
> >    проблемы на этапе линковки, даже если liblapack-devel есть в системе.
> >    Приходится вручную указывать, что линковаться надо с libopenblas + liblapack.
> 
> Это, наверное, плохо. Может быть стоит его собрать с внешним lapack ?

Так сейчас он и используется с внешним lapack. При этом lapack носит
свой blas, и устанавливает man-pages от него. А h-файлов в нем и нет,
они - от clapack. Так что все весьма запутано.

Как я понимаю, идея была сделать liblapack точкой входа, чтобы на него
ставить зависимости, а он уже вытягивал openblas и все нужное в системе
было.

Мне сейчас больше нравится идея собрать obenblas со всеми опциями, со
своими lapack, clapack, многопоточностью. И использовать только его.

Кроме того, наверное хорошо бы иметь отдельный референсный комплект
(blas+xblas+lapack+clapack). Его можно сделать на базе liblapack.
Единственное, что смущает - очень неочевидные названия в этом
случае: "если нужен blas+lapack - использовать либо openblas либо liblapaсk".

> + make -j16 'CFLAGS=-pipe -frecord-gcc-switches -Wall -g -O2 
> -I../include -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM 
> -DUSEGETTIME' 'LIBS=-L../lib -lsdp'
> make: Entering directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
> cc -pipe -frecord-gcc-switches -Wall -g -O2 -I../include 
> -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM -DUSEGETTIME   -c -o 
> csdp.o csdp.c
> make: Leaving directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
> make: Entering directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
> cc -pipe -frecord-gcc-switches -Wall -g -O2 -I../include 
> -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM -DUSEGETTIME csdp.o 
> -L../lib -lsdp -o csdp
> /usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dtrtri_'
> /usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dpotrf_'
> /usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dpotrs_'
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:5: csdp] Error 1
> make: Leaving directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
> error: Bad exit status from /usr/src/tmp/rpm-tmp.39185 (%build)

Да, так это и выглядит. Убирание lapackовских заголовков из openblas
мне, кстати, не сильно помогло. Автоматика в cmake и autotools все равно
считает, что все должно быть в openblas, -llapack надо явно указывать. А
фортрану сишные заголовки вообще не нужны.

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

[Anton Farygin]

On 25.09.2020 15:55, Vladislav Zavjalov wrote:
> On Fri, Sep 25, 2020 at 03:20:56PM +0300, Anton Farygin wrote:
>> On 20.09.2020 16:28, Vladislav Zavjalov wrote:
>>> * openblas -- Оптимизированная версия Blas, с поддержкой
>>>     многопоточных вычислений и т.п.
>>>     https://github.com/xianyi/OpenBLAS
>>>
>>>     Openblas может и сам предоставлять стандартный lapack, но у нас он собран с ключом
>>>     NO_LAPACK=1. При этом в заголовочные файлы функции из lapack попадают, а
>>>     в библиотеку - нет. В результате, при сборке разных программ возникают
>>>     проблемы на этапе линковки, даже если liblapack-devel есть в системе.
>>>     Приходится вручную указывать, что линковаться надо с libopenblas + liblapack.
>> Это, наверное, плохо. Может быть стоит его собрать с внешним lapack ?
> Так сейчас он и используется с внешним lapack. При этом lapack носит
> свой blas, и устанавливает man-pages от него. А h-файлов в нем и нет,
> они - от clapack. Так что все весьма запутано.
>
> Как я понимаю, идея была сделать liblapack точкой входа, чтобы на него
> ставить зависимости, а он уже вытягивал openblas и все нужное в системе
> было.
>
> Мне сейчас больше нравится идея собрать obenblas со всеми опциями, со
> своими lapack, clapack, многопоточностью. И использовать только его.
А как другие дистрибутивы выкручиваются ?
>
> Кроме того, наверное хорошо бы иметь отдельный референсный комплект
> (blas+xblas+lapack+clapack). Его можно сделать на базе liblapack.
> Единственное, что смущает - очень неочевидные названия в этом
> случае: "если нужен blas+lapack - использовать либо openblas либо liblapaсk".
>
>> + make -j16 'CFLAGS=-pipe -frecord-gcc-switches -Wall -g -O2
>> -I../include -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM
>> -DUSEGETTIME' 'LIBS=-L../lib -lsdp'
>> make: Entering directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
>> cc -pipe -frecord-gcc-switches -Wall -g -O2 -I../include
>> -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM -DUSEGETTIME   -c -o
>> csdp.o csdp.c
>> make: Leaving directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
>> make: Entering directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
>> cc -pipe -frecord-gcc-switches -Wall -g -O2 -I../include
>> -I/usr/include/openblas -DNOSHORTS -DUSESIGTERM -DUSEGETTIME csdp.o
>> -L../lib -lsdp -o csdp
>> /usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dtrtri_'
>> /usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dpotrf_'
>> /usr/bin/ld.default: ../lib/libsdp.so: undefined reference to `dpotrs_'
>> collect2: error: ld returned 1 exit status
>> make: *** [Makefile:5: csdp] Error 1
>> make: Leaving directory '/usr/src/RPM/BUILD/csdp-6.2.0/solver'
>> error: Bad exit status from /usr/src/tmp/rpm-tmp.39185 (%build)
> Да, так это и выглядит. Убирание lapackовских заголовков из openblas
> мне, кстати, не сильно помогло. Автоматика в cmake и autotools все равно
> считает, что все должно быть в openblas, -llapack надо явно указывать. А
> фортрану сишные заголовки вообще не нужны.
>
>
Так что делать то ?

Я добавил -llapack и оно собралось, но всё это как-то не красиво.

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

[Vladislav Zavjalov]

On Fri, Sep 25, 2020 at 06:15:46PM +0300, Anton Farygin wrote:
> > Мне сейчас больше нравится идея собрать obenblas со всеми опциями, со
> > своими lapack, clapack, многопоточностью. И использовать только его.
> А как другие дистрибутивы выкручиваются ?

Посмотрел для начала Fedora.
openblas собирается во многих вариантах: serial, pthread, openmp, 32- и
64-bit integer. Так что еще один вопрос возник, надо ли нам так делать?
У нас был только serial, у меня была наивная идея включить и pthread, и
openmp в одну сборку.

Lapack может использоваться внешний или внутрений,
внешний при этом прицепляется статически, .a-файл
из lapack-static включается в openblas.so.
Разницы в этом не очень много, что в lapack, что в openblas - одно
дерево из netlib (впрочем, в lapack у fedora есть несколько патчей).

Как там в spec-файле делается выбор я не очень понял. В x86_64 rpm
стоит Provides: bundled(lapack), что, кажется, означает, что
используется имеено bundled.

Буду еще смотреть.

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

[Andrey Savchenko]

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

On Fri, 25 Sep 2020 18:15:46 +0300 Anton Farygin wrote:
> On 25.09.2020 15:55, Vladislav Zavjalov wrote:
> > On Fri, Sep 25, 2020 at 03:20:56PM +0300, Anton Farygin wrote:
> >> On 20.09.2020 16:28, Vladislav Zavjalov wrote:
> >>> * openblas -- Оптимизированная версия Blas, с поддержкой
> >>>     многопоточных вычислений и т.п.
> >>>     https://github.com/xianyi/OpenBLAS
> >>>
> >>>     Openblas может и сам предоставлять стандартный lapack, но у нас он собран с ключом
> >>>     NO_LAPACK=1. При этом в заголовочные файлы функции из lapack попадают, а
> >>>     в библиотеку - нет. В результате, при сборке разных программ возникают
> >>>     проблемы на этапе линковки, даже если liblapack-devel есть в системе.
> >>>     Приходится вручную указывать, что линковаться надо с libopenblas + liblapack.
> >> Это, наверное, плохо. Может быть стоит его собрать с внешним lapack ?
> > Так сейчас он и используется с внешним lapack. При этом lapack носит
> > свой blas, и устанавливает man-pages от него. А h-файлов в нем и нет,
> > они - от clapack. Так что все весьма запутано.
> >
> > Как я понимаю, идея была сделать liblapack точкой входа, чтобы на него
> > ставить зависимости, а он уже вытягивал openblas и все нужное в системе
> > было.
> >
> > Мне сейчас больше нравится идея собрать obenblas со всеми опциями, со
> > своими lapack, clapack, многопоточностью. И использовать только его.
> А как другие дистрибутивы выкручиваются ?

Здесь есть две ситуации: 
1) используется стандартный интерфейс (C)BLAS/LAPACK(E);
2) используются дополнительные фичи конкретных библиотек.

Во втором случае, очевидно, идёт линковка с конкретными
библиотеками.

А вот первый в Debian очень грамотно решили: поскльку стандартный
интерфейс одинаков, библиотеки с помощью alternatives можно
переключать run-time кому какая больше нравится. По сути, меняются
симлинки, а оригинальные библиотеки изначально распихиваютсся по
своим директориям с переименованием soname по необходимости.
https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

В Gentoo в рамках GSoC реализовали аналогичное решение: можно
собрать все библиотеки с USE="eselect-ldso" и посрдеством eselect
выбирать ту, что больше нравится. Это тоже делается run-time.
https://wiki.gentoo.org/wiki/Blas-lapack-switch

При желании можно даже собрать два варианта одной и той же
библиотеки (например, openblas нельзя собрать одновременно
с pthread и openmp, поэтому можно собрать один вариант с pthread,
а другой с openmp) и тоже между ними переключаться. Но это уже
некоторая морока.

Best regards,
Andrew Savchenko

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

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

[Vladislav Zavjalov]

On Fri, Sep 25, 2020 at 10:52:14PM +0300, Andrey Savchenko wrote:
> Здесь есть две ситуации: 
> 1) используется стандартный интерфейс (C)BLAS/LAPACK(E);
> 2) используются дополнительные фичи конкретных библиотек.
> 
> Во втором случае, очевидно, идёт линковка с конкретными
> библиотеками.
> 
> А вот первый в Debian очень грамотно решили: поскльку стандартный
> интерфейс одинаков, библиотеки с помощью alternatives можно
> переключать run-time кому какая больше нравится. По сути, меняются
> симлинки, а оригинальные библиотеки изначально распихиваютсся по
> своим директориям с переименованием soname по необходимости.
> https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
> 
> В Gentoo в рамках GSoC реализовали аналогичное решение: можно
> собрать все библиотеки с USE="eselect-ldso" и посрдеством eselect
> выбирать ту, что больше нравится. Это тоже делается run-time.
> https://wiki.gentoo.org/wiki/Blas-lapack-switch
> 
> При желании можно даже собрать два варианта одной и той же
> библиотеки (например, openblas нельзя собрать одновременно
> с pthread и openmp, поэтому можно собрать один вариант с pthread,
> а другой с openmp) и тоже между ними переключаться. Но это уже
> некоторая морока.

Спасибо! Понимание постепенно растет.
Надо будет потом тоже такой текст сделать, "как у нас все устроено".
А может, и уже сейчас надо.

Моя идея была в том, чтобы в качестве первого шага сделать два пакета:
openblas (openblas, собранный со своим lapack) и, условно говоря,
refblaslapack (с референсными blas и lapack, из исходников lapack).

Наверное, можно их переключать альтернативами, но, правильно ли я
понимаю, что альтернативы для библиотек - это довольно скользкий
механизм? Программа собирается и линкуется с одной библиотекой, потом ей
подсовывается другая, и никаких механизмов проверки, что они
предоставляют одни символы нет? Например, что будет, если в одну
из библиотек попадут символы из xblas или еще какое-то расширение...

В качестве второго шага можно сделать serial/openmp/pthread версии,
и их как раз кажется правильно переключать альтернативами.