Какая связь между BLAS, LAPACK и ATLAS

BLAS - это набор низкоуровневых матричных и векторных арифметических операций («умножить вектор на скаляр», «умножить две матрицы и добавить к третьей матрице» и т. Д.).

LAPACK - это набор операций линейной алгебры более высокого уровня. Такие вещи, как факторизации матриц (LU, LLt, QR, SVD, Schur и т. Д.), Которые используются для таких вещей, как «найти собственные значения матрицы», или «найти сингулярные значения матрицы», или «решить линейную систему. ». LAPACK построен на основе BLAS; многие пользователи LAPACK только используют интерфейсы LAPACK, и им вообще не нужно знать о BLAS. LAPACK обычно компилируется отдельно от BLAS и может использовать любую имеющуюся у вас высокооптимизированную реализацию BLAS.

ATLAS - это достаточно хорошая переносимая реализация интерфейсов BLAS, которая также реализует несколько наиболее часто используемых операций LAPACK.

То, что «вам следует использовать», в некоторой степени зависит от деталей того, что вы пытаетесь сделать, и от того, какую платформу вы используете. Однако вы не ошибетесь, говоря «используйте ATLAS + LAPACK».

Некоторое время назад, когда я начал заниматься линейной алгеброй в C, я был удивлен, увидев так мало руководств по BLAS, LAPACK и другим фундаментальным API, несмотря на то, что они каким-то образом являются краеугольными камнями многих других библиотек. По этой причине я начал собирать все примеры / руководства, которые смог найти в Интернете для BLAS, CBLAS, LAPACK, CLAPACK, LAPACKE, ATLAS, OpenBLAS ... в это репозиторий Github.

Что ж, я должен вас предупредить, что как инженер-механик у меня мало опыта в управлении таким репозиторием git или GitHub. Сначала это покажется вам полным беспорядком, ребята. Однако, если вам удастся преодолеть запутанную структуру, вы найдете всевозможные примеры и инструкции, которые могут помочь. Я перепробовал большинство из них, чтобы убедиться, что они компилируются. А те, которые не компилируются, я уже упоминал. Я модифицировал многие из них, чтобы их можно было компилировать с GNU compilers (gcc, g++ и gfortran). Я сделал MakeFiles, которые вы можете прочитать, чтобы узнать, как можно вызывать отдельные Fortran/FORTRAN подпрограммы в C или C++ программах. Я также поместил несколько инструкций по установке для Mac и Linux (извините, ребята, Windows!). Я также сделал несколько bash .sh файлов для автоматической компиляции некоторых из этих библиотек.

Но перейдем к вашему другому вопросу: BLAS и LAPACK скорее API, а не конкретные SDK. Это просто список спецификаций или языковых расширений, а не реализации или библиотеки. С учетом сказанного, существуют оригинальные реализации Netlib в FORTRAN 77, на которые большинство людей ссылается (что сбивает с толку! ) если говорить о BLAS и LAPACK. Итак, если вы видите много странных вещей при использовании этих API, это потому, что вы на самом деле вызывали FORTRAN подпрограммы в C, а не C библиотеки и функции. Насколько мне известно, ATLAS и OpenBLAS - одни из лучших реализаций BLAS и LACPACK. Они соответствуют оригиналу API, хотя, насколько мне известно, они реализованы на C/C++ с нуля (не уверен!). Существуют реализации GPGPU для APIs с использованием OpenCL: CLBlast, clBLAS, clMAGMA, ArrayFire и ViennaCL и некоторые другие. Существуют также реализации конкретных производителей, оптимизированные для конкретного оборудования или платформы, и я настоятельно не рекомендую их использовать.

Я рекомендую всем, кто хочет научиться использовать BLAS и LAPACK в C, - сначала изучить FORTRAN-C смешанное программирование. Этому вопросу посвящена первая глава упомянутого репо, в которой я собрал много разных примеров.

PS Я работал над веткой dev репозитория время от времени. Это кажется немного менее беспорядочным!

ATLAS к настоящему времени сильно устарел. Он был разработан в то время, когда считалось, что оптимизация BLAS для различных платформ была за пределами возможностей человека, и в результате автогенерация и автонастройка были подходящим вариантом.

В начале 2000-х появился Казусигэ Гото, который показал, как высокоэффективные реализации можно кодировать вручную. Возможно, вам понравится интересная статья в New York Times: https://www.nytimes.com/2005/11/28/technology/writing-the-fastest-code-by-hand-for-fun-a-human-computer-keep.html.

Казусигэ, с одной стороны, лучше понимал теорию, лежащую в основе высокопроизводительных реализаций матричного умножения, а с другой стороны, лучше их спроектировал. Его подход, который на современных процессорах обычно наиболее эффективен, не относится к области поиска, которую автоматически настраивает ATLAS. Следовательно, ATLAS по своей сути уступает. Внедрение Казусиге BLAS стало известно как GotoBLAS. Когда он пришел в индустрию, он получил ответвление как OpenBLAS.

Идеи, лежащие в основе GotoBLAS, были преобразованы в новую реализацию, платформу BLAS-подобного программного обеспечения для создания библиотек (BLIS) (https://github.com/flame/blis), который реализует те же алгоритмы, но структурирует код так, что для новой архитектуры нужно меньше настраивать. BLIS кодируется на C.

Это обсуждение показывает, что существует множество реализаций BLAS. Сами BLAS являются стандартом де-факто для интерфейса. ATLAS когда-то был самым современным оборудованием. Это уже не так.

Насколько мне известно, и после работы с репозиторием ATLAS, кажется, что он включает повторную реализацию BLAS на C. Это немного больше, чем это, но я надеюсь, что это ответит на вопрос.