From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 20 Sep 2020 23:25:23 +0300 From: Vladislav Zavjalov To: ALT Linux Team development discussions Message-ID: <20200920202523.GJ26263@imap.altlinux.org> References: <20200920103655.GA26263@imap.altlinux.org> <20200920132814.GC26263@imap.altlinux.org> <20200920163457.GA592037@portlab> <20200920184133.GG26263@imap.altlinux.org> <20200920220059.9db5e58134f75b472b94b6a2@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200920220059.9db5e58134f75b472b94b6a2@altlinux.org> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel] =?koi8-r?b?0MHLxdTZIMTM0SDeydPMxc7Oz8fPINPexdTB?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 20:25:23 -0000 Archived-At: List-Archive: List-Post: 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 для Эльбруса. Надо бы, наверное, про все это хозяйство какое-то описание иметь (страницу на вики?)