#lapack — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #lapack, aggregated by home.social.
-
#Copilot and I are about 30% away from creating a #Pascal version of #LAPACK using #BLAS. We are about two days away from achieving 80% of LAPACK. Then we will tweak it using some GPU acceleration to make its speed comparable to some python libraries like Numpy.
It is important to note that one must be very disciplined in keeping clean documentations, a thorough and tight testing cycle, a rigid workflow pattern, or an AI will tend to skip tests, become sloppy and lose focus.
-
Another post on #Quansight PBC blog: "BLAS/LAPACK #packaging"
https://labs.quansight.org/blog/blas-lapack-packaging
"""
#BLAS and #LAPACK are the standard libraries for linear algebra. The original implementation, often called Netlib LAPACK, developed since the 1980s, nowadays serves primarily as the origin of the standard interface, the reference implementation and a conformance test suite. The end users usually use optimized implementations of the same interfaces. The choice ranges from generically tuned libraries such as OpenBLAS and BLIS, through libraries focused on specific hardware such as Intel® oneMKL, Arm Performance Libraries or the Accelerate framework on macOS, to ATLAS that aims to automatically optimize for a specific system.The diversity of available libraries, developed in parallel with the standard interfaces, along with vendor-specific extensions and further downstream changes, adds quite a bit of complexity around using these libraries in software, and distributing such software afterwards. This problem entangles implementation authors, consumer software authors, build system maintainers and distribution maintainers. Software authors generally wish to distribute their packages built against a generically optimized BLAS/LAPACK implementation. Advanced users often wish to be able to use a different implementation, more suited to their particular needs. Distributions wish to be able to consistently build software against their system libraries, and ideally provide users the ability to switch between different implementations. Then, build systems need to provide the scaffolding for all of that.
I have recently taken up the work to provide such a scaffolding for the Meson build system; to add support for BLAS and LAPACK dependencies to Meson. While working on it, I had to learn a lot about BLAS/LAPACK packaging: not only how the different implementations differ from one another, but also what is changed by their respective downstream packaging. In this blog post, I would like to organize and share what I have learned.
""" -
Another post on #Quansight PBC blog: "BLAS/LAPACK #packaging"
https://labs.quansight.org/blog/blas-lapack-packaging
"""
#BLAS and #LAPACK are the standard libraries for linear algebra. The original implementation, often called Netlib LAPACK, developed since the 1980s, nowadays serves primarily as the origin of the standard interface, the reference implementation and a conformance test suite. The end users usually use optimized implementations of the same interfaces. The choice ranges from generically tuned libraries such as OpenBLAS and BLIS, through libraries focused on specific hardware such as Intel® oneMKL, Arm Performance Libraries or the Accelerate framework on macOS, to ATLAS that aims to automatically optimize for a specific system.The diversity of available libraries, developed in parallel with the standard interfaces, along with vendor-specific extensions and further downstream changes, adds quite a bit of complexity around using these libraries in software, and distributing such software afterwards. This problem entangles implementation authors, consumer software authors, build system maintainers and distribution maintainers. Software authors generally wish to distribute their packages built against a generically optimized BLAS/LAPACK implementation. Advanced users often wish to be able to use a different implementation, more suited to their particular needs. Distributions wish to be able to consistently build software against their system libraries, and ideally provide users the ability to switch between different implementations. Then, build systems need to provide the scaffolding for all of that.
I have recently taken up the work to provide such a scaffolding for the Meson build system; to add support for BLAS and LAPACK dependencies to Meson. While working on it, I had to learn a lot about BLAS/LAPACK packaging: not only how the different implementations differ from one another, but also what is changed by their respective downstream packaging. In this blog post, I would like to organize and share what I have learned.
""" -
Wspominałem już może, że pracuję nad przejściem #Gentoo z na wpół zepsutego eselect-ldso dla #BLAS / #LAPACK, na #FlexiBLAS. Oznacza to również, że czeka nas okres przejściowy, w czasie którego obydwa rozwiązania będą wspierane.
Plus jest taki, że stan "po" jest kompatybilny pod względem ABI ze stanem "przed" (a przynajmniej powinien być — pracujemy z autorami, by poprawić ostatnie niedociągnięcia). Zastępujemy libblas.so, liblapack.so i inne biblitoteki dowiązaniami symbolicznymi, więc programy skompilowane przed zmianą po prostu zaczną używać FlexiBLAS.
Minus jest taki, że w drugą stronę nie jest tak łatwo. Po zastąpieniu biblitotek dowiązaniami, nowoskompilowane programy będą odczytywać SONAME z biblioteki docelowej, a więc zaczną się wiązać bezpośrednio z FlexiBLAS. Co za tym idzie, powrót do stanu poprzedniego będzie wymagał ich ponownej kompilacji.
Aby tego uniknąć, musielibyśmy zamiast dowiązań symbolicznych zastosować jakieś biblioteki pośredniczące, które miałyby "stare" SONAME, a korzystąły z funkcji FlexiBLAS. Niestety, nic prostego tu nie zadziała — musiałbym jakoś "wyeksportować" symbole z FlexiBLAS, i najlepiej podzielić je na odpowiednie biblioteki, żeby `-Wl,--as-needed` nic nie wycięło. Tylko jak to zrobić?
Cóż, eselect-ldso tworzy jakieś biblioteki, więc może uda się coś wykorzystać. No i szukam w źródłach, i nic nie mogę znaleźć. W końcu do mnie dociera, że cała logika dodana jest przez łatki Gentoo. A te łatki są po prostu paskudne. W OpenBLAS tworzymy dodatkowe biblioteki libblas.so, itp., które zawierają kopie obiektów z OpenBLAS i wiążą się z libopenblas, żeby pobrać brakujące zależności. Nawet nie wiążą się jedna z drugą, więc każda duplikuje sporo kodu niezależnie. Łatki dla BLIS są jeszcze gorsze — tu libblas.so i libcblas.so to praktycznie kopie libblis.so, z poszczególnymi "niepotrzebnymi" symbolami ukrytymi przy pomocy "visibility".
No cóż, można się było tego spodziewać po projekcie z #GSoC.
-
1. Zdobądź trochę wiedzy o paczkach #BLAS / #LAPACK w ramach bejmopracy.
2. Odkryj, że paczki #MKL w #Gentoo są mocno nieaktualne i ciut zepsute. Przejmij je, zaktualizuj, ulepsz.
3. Zainteresuj się #FlexiBLAS. Zacznij eksperymentować. Wrzuć paczkę do Gentoo.
4. Odkryj, że mechanizm dynamicznego przełączania BLAS / LAPACK niezbyt dobrze działa. Zaproponuj migrację do FlexiBLAS i przygotuj próbne zmiany.
5. Zauważ niespójności we wsparciu ILP64. Zaproponuj poprawki.
6. Odkryj, że wszystkie paczki BLAS / LAPACK w Gentoo są praktycznie bez opiekuna.No więc wygląda na to, że jestem nowym opiekunem całego kompletu. Pracuję nad poprawkamj dla ILP64, a następnie będę musiał zaktualizować łatki dla migracji do FlexiBLAS.
-
1. Learn a bit about #BLAS / #LAPACK packaging for dayjob.
2. Learn that #MKL in #Gentoo is quite outdated. Take it over, bump it and improve the packaging.
3. Get curious about #FlexiBLAS. Start playing with it. Package it for #Gentoo.
4. Learn that runtime BLAS / LAPACK switching is quite broken. Come up with a FlexiBLAS transition plan and a proof-of-concept.
5. Notice inconsistency in ILP64 support flags. Propose unifying the behavior.
6. Learn that BLAS / LAPACK packages in Gentoo are pretty much unmaintained.Well, looks like I'm the new maintainer of the whole stack, I'm working on consistent ILP64 support now, and then I'll have to rebase the FlexiBLAS transition bits.
-
1. Learn a bit about #BLAS / #LAPACK packaging for dayjob.
2. Learn that #MKL in #Gentoo is quite outdated. Take it over, bump it and improve the packaging.
3. Get curious about #FlexiBLAS. Start playing with it. Package it for #Gentoo.
4. Learn that runtime BLAS / LAPACK switching is quite broken. Come up with a FlexiBLAS transition plan and a proof-of-concept.
5. Notice inconsistency in ILP64 support flags. Propose unifying the behavior.
6. Learn that BLAS / LAPACK packages in Gentoo are pretty much unmaintained.Well, looks like I'm the new maintainer of the whole stack, I'm working on consistent ILP64 support now, and then I'll have to rebase the FlexiBLAS transition bits.
-
Próbowałem dodać #FlexiBLAS do #Gentoo, i szczerze mówiąc, nie wygląda to dobrze.
Na dobry początek niepokoi brak otwartego systemu zgłaszania błędów. Jest GitLab, ale ograniczony do "członków ich grupy i wybranych osób z zewnątrz", ale nie wygląda na to, żeby go za bardzo używano. Jest tylko "wyślij nam maila", a potem zastanów się, ile osób zgłosiło wcześniej ten sam problem.
Repozytorium git jest aktualnie na wersji oznaczonej jako 3.4.80, która wydaje się wczesną wersją testową, i jej system budowania jest całkiem spieprzony. Nie ułatwia to weryfikacji, czy problemy, z którymi dziś mam do czynienia, są nadal aktualne.
Wygląda na to, że autorzy wspierają wyłącznie albo użycie #LAPACK-a włączonego w swoją paczkę, albo statycznie wiązanie z biblioteką systemową (nie instalujemy jej w Gentoo). Mogę niby podać ścieżkę do biblioteki dynamicznej, ale nie działa — i nie wiem, czy nie działa, bo używam biblioteki dynamicznej, czy może dlatego, że FlexiBLAS nie wspiera mojej wersji LAPACK-a. Jeżeli LAPACK-a mam zbudowanego bez przestarzałych symboli, FlexiBLAS odmawia załadowania go ze względu na brakującego symbole. Jeżeli załączę przestarzałe symbole, to wtedy FlexiBLAS sypie się już na poziomie konfiguracji, z powodu innych brakujących symboli.
Mam wrażenie, że już zmarnowałem zbyt dużo czasu na ten projekt, zwłaszcza, że jego przyszłość jest niejasna. Aktualna wersja z git jest zepsuta, nie wiem, ile już problemów zgłoszono, i czy w ogóle otrzymam jakąś odpowiedź na moje zgłoszenia. Nie świadczy to dobrze o paczce, która może stać się istotna dla dystrybucji. Nie chcemy tu katedry.
https://www.mpi-magdeburg.mpg.de/projects/flexiblas
https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release -
I was trying to package #FlexiBLAS for #Gentoo, and to be honest, it doesn't look that good.
The first red flag is lack of an open bug tracker. Apparently, there is the tracker on GitLab that's limited to "members of their group and selected external contributors", but it doesn't seem to be used much. So it's "send us an email", and wonder how many people sent us the same bug report before.
The git repository is currently at something tagged 3.4.80 that seems to be prerelease, and its build system is quite broken. Not exactly the best path to verify that the bugs you are hitting are still there.
Now, upstream seems to insist on either using vendored netlib #LAPACK, or statically linking to the system library (we don't install the static libraries). Apparently I can specify the shared libraries instead, but it doesn't work — and it's unclear to me whether it doesn't work because I'm using the shared libraries, or because it doesn't support my LAPACK version. If I build LAPACK without deprecated symbols, it refuses to load it at runtime because of missing symbols. And if I build it with deprecated symbols, it fails to find some symbols at CMake time.
Honestly, I feel like I've spent too much time on this project already, especially given that its future is entirely unclear to me — the current git is quite broken, I have no clue how many issues were reported already and whether my bug reports will receive any reply. It definitely doesn't fare well for a package that we might start to rely heavily on. We don't want a cathedral there.
https://www.mpi-magdeburg.mpg.de/projects/flexiblas
https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release -
I was trying to package #FlexiBLAS for #Gentoo, and to be honest, it doesn't look that good.
The first red flag is lack of an open bug tracker. Apparently, there is the tracker on GitLab that's limited to "members of their group and selected external contributors", but it doesn't seem to be used much. So it's "send us an email", and wonder how many people sent us the same bug report before.
The git repository is currently at something tagged 3.4.80 that seems to be prerelease, and its build system is quite broken. Not exactly the best path to verify that the bugs you are hitting are still there.
Now, upstream seems to insist on either using vendored netlib #LAPACK, or statically linking to the system library (we don't install the static libraries). Apparently I can specify the shared libraries instead, but it doesn't work — and it's unclear to me whether it doesn't work because I'm using the shared libraries, or because it doesn't support my LAPACK version. If I build LAPACK without deprecated symbols, it refuses to load it at runtime because of missing symbols. And if I build it with deprecated symbols, it fails to find some symbols at CMake time.
Honestly, I feel like I've spent too much time on this project already, especially given that its future is entirely unclear to me — the current git is quite broken, I have no clue how many issues were reported already and whether my bug reports will receive any reply. It definitely doesn't fare well for a package that we might start to rely heavily on. We don't want a cathedral there.
https://www.mpi-magdeburg.mpg.de/projects/flexiblas
https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release -
If you had to do a lot of dense linear algebra (QR eigenvalues, SVD, linear least squares, etc.) on modern AMD *CPUs*, which library would you choose for maximum performance? #HPC #BLAS #LAPACK #linearalgebra #NumericalSimulation #amd
-
If you had to do a lot of dense linear algebra (QR eigenvalues, SVD, linear least squares, etc.) on modern AMD *CPUs*, which library would you choose for maximum performance? #HPC #BLAS #LAPACK #linearalgebra #NumericalSimulation #amd
-
The annual @gnuradio conference just started!
Turing laureate Jack Dongarra is the first keynote speaker! If you ever used LAPACK, BLAS (and you did – whether you know it or not), read the top500 supercomputer list, or are just all for sharing numerical libraries – you want to head to the streams on https://grcon.stream
#grcon24 #livestream #LAPACK #BLAS #FORTRAN -
The annual @gnuradio conference just started!
Turing laureate Jack Dongarra is the first keynote speaker! If you ever used LAPACK, BLAS (and you did – whether you know it or not), read the top500 supercomputer list, or are just all for sharing numerical libraries – you want to head to the streams on https://grcon.stream
#grcon24 #livestream #LAPACK #BLAS #FORTRAN -
No fail, no gain: как мы исправили более миллиона тестов, проверяя оптимизацию библиотеки OpenBLAS под RISC-V
Открытая архитектура RISC-V активно развивается: в стандарт добавляются новые расширения и инструкции, разрабатываются новые ядра и SoC. Поскольку многие компании видят перспективы архитектуры и готовы использовать ее в продакшене, создается программный стек для высокопроизводительных вычислений — RISC-V HPC (High Performance Computing). Прогресс сопровождает формирование нового тренда — OpenHPC. Он заключается в технологической независимости от решений коммерческих компаний. Причем это относится не только к ПО, но и к железу. Чтобы концепция OpenHPC реализовывалась быстрее, нужно, чтобы к инициативе присоединилось как можно больше компаний, помогающих в развитии экосистемы решений для RISC-V HPC. Меня зовут Андрей Соколов, я инженер-программист в компании YADRO. В R&D-команде мы поставили перед собой задачу: изучить, как можно поддержать архитектуру RISC-V со стороны библиотек линейной алгебры BLAS и LAPACK. Тестирование одной из open source-библиотек привело нас к интересным открытиям, о которых я расскажу под катом. Результаты тестов
https://habr.com/ru/companies/yadro/articles/821715/
#openblas #blas #lapack #линейная_алгебра #библиотеки #оптимизация #riscv
-
C++26 — прогресс и новинки от ISO C++
Работа в комитете по стандартизации языка C++ активно кипит. Недавно состоялось очередное заседание. Как один из участников, поделюсь сегодня с Хабром свежими новостями и описанием изменений, которые планируются в С++26. До нового стандарта C++ остаётся чуть больше года, и вот некоторые новинки, которые попали в черновик стандарта за последние две встречи: запрет возврата из функции ссылок на временное значение, [[indeterminate]] и уменьшение количества Undefined Behavior, диагностика при =delete; , арифметика насыщения, линейная алгебра (да-да! BLAS и немного LAPACK), индексирование variadic-параметров и шаблонов ...[42] , вменяемый assert(...) , и другие приятные мелочи. Помимо этого, вас ждут планы и прогресс комитета по большим фичам и многое другое. Рассмотрим новинки на примерах
https://habr.com/ru/companies/yandex/articles/801115/
#c++ #с++ #constexpr #c++26 #с++26 #numeric #floating_point #float #double #iso #программирование #span #functions #function #blas #lapack #atomic #linear_algebra #variadic_templates
-
Could anyone please tell me what the difference is between all the following #lapack libraries???
liblapack
libblas
libopenblas
blas-devel
openblas
libcblas
liblapackeAnd why does "conda install blas-devel" install all of these?
-
Could anyone please tell me what the difference is between all the following #lapack libraries???
liblapack
libblas
libopenblas
blas-devel
openblas
libcblas
liblapackeAnd why does "conda install blas-devel" install all of these?
-
Язык Crystal и математика
Если вам вдруг захотелось посчитать собственные значения матрицы, решить задачу линейного программирования или оптимизировать нелинейную функцию, то вы может взять питон со SciPy, можете взять R или Matlab\Octave, для любителей экзотики есть Julia, а те кому важен каждый тик скорее возьмут C++ или Rust. Но если вдруг вы хотите взять Crystal (оставим за кадром причины этого решения), то я постараюсь описать что он может предложить для решения математических задач.
-
🖥️💪 Do you struggle with numerical efficiency in your work? 🤔👨💼 Marcin Błażejowski has the answer! 💡👨🏫
Presented at the #gretl conference 2023 work on "Which C compiler and #BLAS/ #LAPACK library should I use?" to learn expert insights on configuration that boosts your work efficiency.
#numeralanalysis #economics #econometrics #gc2023 #econtwitter
-
It seems that Chris Zimmerman is unstoppable.
Now he started porting @[email protected]'s draw2d to #CrystalLang:https://github.com/crystal-data/draw.cr
Wow, Chris Zimmerman from Knowledge Based Systems (#KBSI) created some alternatives for #numpy / scientific computing libraries in @[email protected]:
https://github.com/crystal-data/
i.e. bindings for @[email protected] / @[email protected] & calculations with #OpenBLAS or #LAPACK.
🐦🔗: https://twitter.com/alexanderadam__/status/1232247965336645632