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

[Andrey Savchenko]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20200920/6f95367f/attachment.bin>