Рекомендации для легкого / не устанавливаемого C или C ++ решения для плотной линейной алгебры

9

Большая часть моего программирования - это одноразовые исследовательские коды на Си для моего собственного использования. Я никогда не распространял никакого кода, кроме близких соавторов. Я разработал алгоритм, который я публикую в научном журнале. Я хочу предоставить исходный код и, возможно, исполняемый код в онлайн-дополнении к статье. Коллега попросил, чтобы я сделал обобщение для алгоритма, который требовал от меня писать на C ++ (ack!) И который требовал, чтобы я решал небольшие плотные линейные системы. Если мне удастся получить пользовательскую базу для алгоритма, это будет отчасти потому, что полоса ввода для его использования низкая (как на полу). Потенциальные пользователи не будут устанавливать библиотеки и т. Д. Для использования кода. Я хочу, чтобы код был полностью автономным и не обремененным какой-либо лицензией. Я мог бы просто написать свой собственный решатель, взяв что-то из Голуба и Ван Лоан, но я бы предпочел использовать решатель ванили, который уже написал кто-то другой, если таковые имеются. Предложения приветствуются. Спасибо!

СЭП
источник
Уважаемый джип, добро пожаловать на форум. Ваш вопрос очень похож на приведенный здесь: scicomp.stackexchange.com/questions/351/…
GertVdE
Решатели библиотек, как правило, сложны и велики ради надежности, эффективности и универсальности. Если ваши проблемы очень малы и достаточно хорошо обусловлены, я бы предложил вам написать собственную мини-реализацию.
Стефано М
@GertVdE, спасибо за быстрый ответ на этот вопрос. Мне неудобно ссылаться на вопрос «Рекомендации ...», потому что и вопрос, и основной ответ слишком общие, чтобы оказывать какую-либо помощь в подобных ситуациях. Если вы хотите обсудить это дальше, я предлагаю перенести его в чат Scicomp .
Арон Ахмадиа
@AronAhmadia: Я думаю, что единственный способ начать урегулирование некоторых из этих споров - это начать реализовывать компьютерную науку программирования, которая зависит как от языка, так и от библиотеки. Если код понятен, и о проблемах конфигурации можно решить (используя сценарий оболочки, Chef или Puppet), тогда можно обсудить вопрос о производительности (или конкретизировать), просто запустив код и синхронизировав его с эталонная машина. Споры о ясности могут быть разрешены (или, по крайней мере, сделаны более конкретными), если взглянуть на код. Иначе у нас будут одни и те же аргументы.
Джефф Оксберри

Ответы:

7

Я бы посоветовал точно продублировать интерфейс Lapack с нужной вам функцией, скорее всего, вам просто нужно dgesv. Таким образом, люди, у которых установлен Lapack, могут просто ссылаться на него, и он просто будет работать. Для людей, у которых не установлен Lapack, вы предоставляете собственную простую реализацию этой функции или, возможно, реализуете ее с использованием Eigen или FLENS, как предлагали другие.

На земле Фортран библиотека Лапак является таким стандартом, что большинство людей просто используют ее и все, вместо того, чтобы предоставлять свои собственные реализации.

Ондржей Чертик
источник
+1 Добавьте к этому тот факт, что большинство дистрибутивов Linux (по крайней мере, на основе Debian) имеют двоичные пакеты в репозитории, и все поставляемые поставщиком математические библиотеки (MKL, SunPerf, ACML, ESSL и т. Д.) Несут его. Вы должны всегда использовать как можно больше стандартных библиотек, хотя, если вы работаете в Windows / Mac, вам лучше использовать что-то на C, так как установка на них бесплатного компилятора Fortran (gfortran) - это определенная работа, или, как я слышал.
Стали
Я много раз использовал лапак, но в настоящее время я не нахожусь в Фортране. Я ожидаю, что статистическое распределение платформ, на которых работает моя пользовательская база, будет таким же, как в мире в целом, то есть, в основном, окнами, меньшим процентом macs и еще меньшим процентом * nix. Мой опыт работы с окнами минимален, и я предпочитаю оставить его таким. Вот почему я хочу отдельный код C ++. Я полагаю, что мне придется предоставить некоторым моим пользователям помощь в получении кода для компиляции и запуска. Мне нужно минимизировать работу, необходимую для этого.
СЭП
Если ваша пользовательская база - Windows / Mac, то вам лучше использовать простую реализацию на C (возможно, даже вашу собственную). Пакет, который трудно установить или зависит от 5 других библиотек, особенно когда нет доступного хранилища двоичных пакетов первого класса (например, Debian), надолго отключит ваших пользователей. Помните, что большинство пользователей Windows / Mac привыкли к установке в один клик. Простота использования торжествует все остальное.
Стали
5

Очень ранняя ошибка, которую делают многие люди, когда начинают работать в области научных вычислений, предполагает, что вам нужно написать весь код на одном языке. Я думаю, что это во многом связано с историческими причинами, когда не было ясно, как заставить скомпилированные программы взаимодействовать друг с другом даже между версиями одного и того же компилятора. Тем не менее, в этом случае, если вы все равно собираетесь использовать C ++, есть несколько очень хороших библиотек шаблонов только для заголовков C ++, которые могут соответствовать вашим потребностям.

Поскольку вы распространяете свой код по академическим соображениям и хотели бы встроить в ваш код плотный решатель линейной алгебры, я настоятельно рекомендую вам рассмотреть Eigen . Eigen был лицензирован под публичной лицензией Mozilla и является библиотекой только для заголовков. Это означает, что вы можете распространять Eigen с вашим кодом в исходной форме (это не накладывает никаких лицензионных ограничений на ваш код), и вы получите доступ к его общим возможностям, включая чрезвычайно эффективные плотные линейные решатели. Как упоминает GertVdE, у вас есть несколько других вариантов .

Арон Ахмадия
источник
Я надеялся на один файл. Я занимался научным программированием довольно давно. Я немного смешал языки вроде C и Fortran, но для этого проекта мне просто нужен один файл, содержащий весь мой исходный код. Я полагаю, я мог бы поместить решатель C в код C ++, что не было бы большой проблемой. В основном я хочу, чтобы код был максимально простым. ЛУ с поворотом должен быть адекватным. Я посмотрю на Эйгена. Спасибо!
СЭП
@jep, вы также можете попробовать выбрать нужные вам процедуры из CLAPACK, если вы действительно не заботитесь о производительности.
Арон Ахмадиа
Есть веские причины для написания всего зависимого кода на одном языке, в частности, в средах HPC, у вас есть странные проблемы компиляции / связывания и 32/64-битные проблемы интерфейса. Например, как узнать ширину целого числа для встроенных библиотек? Как я точно знаю, какой компилятор использовался для встроенной библиотеки, и могу ли я связать его с этим другим компилятором? Наличие всего на одном языке упрощает многие из этих проблем. И да, должна быть документация, предоставленная сопровождающими кластера, но большую часть времени там нет.
Виктор Лю
@VictorLiu - проблемы, на которые вы ссылаетесь, более тесно связаны с реализациями, чем с языками. Место для комментариев - плохое место для серьезной дискуссии, но я рад пригласить вас в чат или в другое место, если вы хотите, чтобы я поделился своими мыслями по этому поводу.
Арон Ахмадиа
4

Если вам нужен надежный решатель для систем линейных уравнений, я бы порекомендовал FLENS . Он содержит точную повторную реализацию LAPACK (он даже воспроизводит те же ошибки округления, что и LAPACK, если используется однопоточная реализация BLAS). Это верно для всех функций FLENS-LAPACK (вместе с функциями утилит около 100 подпрограмм).

FLENS находится под лицензией BSD и поэтому позволяет быть включенным в проприетарные продукты.

FLENS - это только заголовок, и если вам нужен только поднабор FLENS, я могу предоставить вам урезанную версию, содержащую только те функции, которые вам нужны. FLENS поставляется со своей собственной реализацией BLAS. Но по желанию ваши пользователи могут ссылаться на оптимизированные библиотеки BLAS, такие как ATLAS, OpenBLAS или GotoBALS. Для больших матриц это дает прирост производительности примерно на 40% по сравнению с Eigen.

И да, Eigen также использует набор тестов LAPACK, чтобы проверить их результаты. Они делают это для 3 функций (Lu, Cholesky и собственные значения / -векторы симметричной матрицы). Однако их вычисление собственных значений / векторов несимметричной матрицы не выполнит тестовый набор LAPACK.

Отказ от ответственности: Да, FLENS мой ребенок! Это означает, что я написал около 95% кода, и каждая строка кода стоила того.

Майкл Лен
источник
1
Майкл - Пожалуйста, сочтите это дружеским предупреждением о том, что вам нужно следовать правилу в FAQ, касающемуся раскрытия принадлежности .
Арон Ахмадиа
Конечно, но вы также можете перефразировать ваши посты из «Я настоятельно рекомендую вам рассмотреть Eigen», например «есть, например, Eigen». В этом случае я удаляю свои замечания о Эйгене (хотя все они подтвердились), в том числе и это.
Майкл Лен
1
Ваши замечания по поводу Эйгена здесь не обсуждаются (хотя они кажутся мне не по теме). Вы являетесь основным разработчиком FLENS, если вы собираетесь порекомендовать его в ответе здесь, вы должны раскрыть свою принадлежность как разработчика проекта.
Арон Ахмадиа
Ах, тогда ладно. Я думал, что это было безоговорочно ясно "... я могу дать вам ...". Раскрыто ли в этой форме нормально?
Майкл Лен
2
Я просто хочу сказать спасибо за это; У меня были аналогичные планы по повторной реализации большей части Lapack в C ++. Тем не менее, кажется, что для большинства продвинутых (собственных значений) подпрограмм вы просто откладываете вызов в Lapack, так что это немного ложная реклама, чтобы сказать, что вы заново реализуете все это. С другой стороны, я фактически перенес исходный код ZGEEV на C ++ в RNP , хотя некоторые части все еще находятся в индексировании на основе 1 из автоматического преобразования.
Виктор Лю