[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