smath 1.0.0 — библиотека линейной алгебры для языка C++ (стандарт C++23)

Знаете что вот я скажу по этому поводу. Есть целая шайка библиотек которые занимаются задачами линейной оптимизации. Вот если бы их к этой библиотеке присобачить ой как хорошо бы было. Используются они кстати в проекте openroad, которые заявляется как инструмент для быстрого прототипирования и разработки микросхем. Ну по правде говоря он скорее инструмент для быстрого прожига жеппы, но не могу не отметить того факта что вот этой библиотеки недостаточно. Как правило всё равно приходится решать там или иначе задачу оптимизации.

хотел было посмотреть, но тут

в виде единственного небольшого заголовочного файла.

то есть единственное что явно точно есть - длительность компиляции и лошадиного размера объектники

Ну это как раз не проблема. Во всяком случае для тех кто будет этим пользоваться. Дело в том что подобные вот библиотеки они в принципе очень часто состоят из кучи заголовков. Если там есть тяжёлый алгоритм то он как раз выносится в исходники. Но большинство таких вот библиотек они используют довольно стандартные и простые алгоритмы.

когда уж работу с матрицами завезут в стандарт? Или студенты еще лет 50 будут изобретать велосипед

длительность компиляции и лошадиного размера объектники

В Handmade-Math тоже единственный хидер, но там и SIMD и другие полезные функции.
$ stat HandmadeMath.h smath.hpp:

File: HandmadeMath.h
Size: 105806

File: smath.hpp
Size: 36590

Может быть smath когда-нибудь и будет использовать std::simd, посмотрим.

когда уж работу с матрицами завезут в стандарт?

В C++26 собирались: https://cppreference.com/w/cpp/numeric/linalg.html.

https://github.com/kokkos/stdBLAS:

This is a reference implementation of P1673, «A free function linear algebra interface based on the BLAS.» You can find the latest submitted revision of P1673 at this URL.

https://github.com/BobSteagall/wg21:

Work on revision R7 of linear algebra proposal P1385 is currently underway in the r7y branch. We are targeting C++26.

Ну это как раз не проблема. Во всяком случае для тех кто будет этим пользоваться

вот как раз вот время компиляции и размер объектников (кстати под их большой размер ещё и опции ликера надо менять, для всего проекта), сцуко критичны. Всякие SIMD? ну сколько они дадут ?? 15% на спец-тестах. А нервы бесценны

если бы я был гением и мог посмотрев документацию с первого-же раза фигакнуть релиз, тогда другое дело. Или достаточно миллиордерен, чтобы за меня страдал кто-другой :-)

понаступав на грабли однажды, теперь хидер-онли библиотеки идут на@# сразу. Они времени отжирают просто тьму

Если вам симд дают 15% то возможно проблема в руках. Возможно они растут из пяток и если бы они росли из жопы то производительность была бы лучше

Кошерно

понаступав на грабли однажды, теперь хидер-онли библиотеки идут на@# сразу. Они времени отжирают просто тьму

Ну вот, а мне помнится тут рядом, на этом самом сайте, затирали про то что время конпеляния «не критично» (особая аллергическая реакция на ключевое слово forward), а нужна их безудержная дрочь на собирание статических бинарей, оптимизацию всего (особенно, без профайлинга, что именно тормозит... у них как обычно тормозил ввод-вывод, делали они что-то не так). А на деле чаще заказчика не колыхает почему оно еще компиляется, когда оно уже на проде должно быть :)

Так там же шаблоны, они не существуют в компилированнгм бинарном виде. А если для всего мыслимого пространства шаблонных параметров подстановки компилять - вот тогда будет нереальный монстр.

Стандартное обычно говенно в разной степени для различных применений. Яркий пример - потоки (stream).

когда уж работу с матрицами завезут в стандарт?

Есть Eigen, есть блас.

Или студенты еще лет 50 будут изобретать велосипед

Наличие чего-то в std:: никогда не мешало народному творчеству.

ок, мы поняли, что по части языка программирования тут всё супер «ново, модно, молодёжно». А как обстоят дела собственно по части линейной алгебры помимо «адаптеров к известным библиотекам» ? Шаблоны Vec<N, T> и Mat<N, M, T> это велосипеды велосипедов, и я, откровенно говоря, постеснялся бы на этом акцентировать внимание.

Стандартное обычно говенно в разной степени для различных применений. Яркий пример - потоки (stream).

Говенность велосипедов, можно подумать, «лучше». Обычно преувеличение недостатков стандартного — это отмаза для наколенных поделок, которые ломаются от любого чиха, а «лучше»(чаще всего под этим подразумевается «быстрее») только из-за отсутствия необходимых проверок. Яркий пример — «проверка» строки формата только на длину, из-за которой биржевой сервак в проде упал. Ну и затраты времени на изобретение велосипеда никто не отменял.

Кончается это тем, что все велосипеды рано или поздно выпиливаются К.Е.М., срезания углов банятся на ревью, линтерами и хуками гита.

Иногда сразу, иногда — после крупного разбора полетов велосипедистов над гнездом их поехавшей кукушки.

Велосипеды чаще всего написаны на протухшем диалекте с забаненными в новом стандарте способами выстрелить в ногу. Т.е. банально перестают собираться со всеми включенными проверками компилятора. Да и сопровождать все эти autoptr2, string3, fast_buffer_ng и прочие поделия велосипедистов, разбросанные там и сям по кодовой базе, сил и желания ни у кого нет. Пристальных проверок и банального фаззинга большинство велосипедов не выдерживает, потому что не решает задачу в общем виде и ломается примерно сразу, примененное там, где автор «и не думал» (ой, надо же), но «забыл» это явно ограничить. Т.к. внятной документации у велосипедов нет. Чаще всего там только срезанные углы у квадратных колес — лишь поэтому ведосипед «работает» в моменте, пока автор не уволился.

Велосипеды чаще всего написаны на протухшем диалекте с забаненными в новом стандарте способами выстрелить в ногу. Т.е. банально перестают собираться со всеми включенными проверками компилятора

Ну вот у меня есть пример, когда «велосипед», начатый в первой половине 2000х никаких «забаненных способов» не использует, собирался новым компилятором в стандарте С++17 без проблем, и «велосипед» этот до сих пор генерит добавочную стоимость. В С++ вообще мало «забаненных способов». На ум приходит только auto_ptr. А если ты про хождение по граблям в вопросах безопасности памяти, рейс кондишн и всего этого - тут, конечно, все уже знают, что С++ требует десятков лет опыта разработки на нём, чтобы все эти грабли обходить. Тут спору нет.

И абстракции, которые этот велосипед реализовал, их, естественно в стандартном с++ тогда не было (треды, например). Но иные вещи в С++ до сих пор не изменились, и никогда не изменятся. Например, базовая библиотека, прочно завязанная на STL и исключения.

Fortran же есть

И вообще, С++ - это инструмент для выскококвалифицированных профессионалов, а не для вайб-кодеров, которые всю юность в макдаке хрючево продавали, а теперь вдруг решили стать айтишниками, купили подписку на Claude и стали генерить тонны неподдерживаемой расто-лапши.

ИИ накодит щас всё)

Правильно ли я понимаю, что о каких-то высокопроизводительных вычислениях тут речь не идёт, иначе где-то должно было промелькнуть слово «BLAS»? Какая тогда область применения этой библиотеки?

Правильно ли я понимаю, что о каких-то высокопроизводительных вычислениях тут речь не идёт

Да. Но это же первая версия.

Какая тогда область применения этой библиотеки?

Кому не нужны монстры типа GLM и Eigen, и высокопроизводительные вычисления. + C++23.

Вопрос, кто-то может сравнить с Armadillo?

От себя могу сказать:

1. В Armadillo нет Quaternion.
2. Armadillo по капотом умеет в OpenMP и прочие высокопроизводительные штуки (но руками иногда результаты получаются лучше)

С simd нужно учитывать накладные расходы на снаряжение расчёта. Но таки да, это как раз про «руки из пяток»: нужно прорабатывать алгоритм.

Armadillo

3. Есть матрицы с изменяемым размером.

3. Есть матрицы с изменяемым размером.

Да, точно! Это в arma.

smath используется в проекте автора https://github.com/slendidev/lunar, видимо для него и писалась.

В meson.build написано, что это vr-compositor, но я не пробовал собирать, потому что там Wayland. :)

понаступав на грабли однажды, теперь хидер-онли библиотеки идут на@# сразу. Они времени отжирают просто тьму

Так делаешь отдельный .cpp под свои параметры и экспортируешь из него уже скомпилированное. Компилируешь этот .cpp в .o ровно один раз.

Ну насколько же должен быть всратым алгоритм линейной алгебры чтоб его simd не ускорял.