Bengal SIR: ECI to give list of excludable voters to BLAs for better transparency #BengalSIRECI #BLAs #socialnewsxyz

https://www.socialnews.xyz/2025/12/11/bengal-sir-eci-to-give-list-of-excludable-voters-to-blas-for-better-transparency/

tritonBLAS: Triton-based Analytical Approach for GEMM Kernel Parameter Selection

#Triton #BLAS #GEMM #AMD #ROCm #HPC #Performance #Package

https://hgpu.org/?p=30441

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.
"""

#CondaForge #Debian #Fedora #Gentoo

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.

High Performance Matrix Multiplication

#CUDA #OpenMP #BLAS #Performance #Package

https://hgpu.org/?p=30188

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.

Widzisz, że osoba z adresem e-mail #Debian .org opiekuje się paczkami #BLAS w #Gentoo, i myślisz sobie: "jak fajnie, że dystrybucje współpracują…"

A potem uświadamiasz sobie, że ta osoba wzięła tylko kasę z #GSoC w 2019, i zniknęła od razu po fakcie…

#WolneOprogramowanie

Harnessing Batched BLAS/LAPACK Kernels on GPUs for Parallel Solutions of Block Tridiagonal Systems

#ROCm #CUDA #BLAS #Factorization #Package

https://hgpu.org/?p=30168

So, do all #BLAS functions scale linearly only up to 4-6 threads? This seems to be the case when multithreaded BLAS is used for glm(m) modeling in #Rstats
#HPC

So, do all #BLAS functions scale linearly only up to 4-6 threads? This seems to be the case when multithreaded BLAS is used for glm(m) modeling in #Rstats
#HPC

So, do all #BLAS functions scale linearly only up to 4-6 threads? This seems to be the case when multithreaded BLAS is used for glm(m) modeling in #Rstats #HPC

New Artist announced for Rock en Seine 2025: 🔥 Blasé 🔥

🎶 Listen to the current LineUp on YouTube and Spotify: https://fyrefestivals.co
🎟️ Get your Tickets now: https://prf.hn/l/EJnYMdO

#Rock_en_Seine_2025 #Blas #fyre_festivals #livemusic #youtube #spotify #music #musicfestivals #playlist #tickets #announcement

Even now, Thrust as a dependency is one of the main reason why we have a #CUDA backend, a #HIP / #ROCm backend and a pure #CPU backend in #GPUSPH, but not a #SYCL or #OneAPI backend (which would allow us to extend hardware support to #Intel GPUs). <https://doi.org/10.1002/cpe.8313>

This is also one of the reason why we implemented our own #BLAS routines when we introduced the semi-implicit integrator. A side-effect of this choice is that it allowed us to develop the improved #BiCGSTAB that I've had the opportunity to mention before <https://doi.org/10.1016/j.jcp.2022.111413>. Sometimes I do wonder if it would be appropriate to “excorporate” it into its own library for general use, since it's something that would benefit others. OTOH, this one was developed specifically for GPUSPH and it's tightly integrated with the rest of it (including its support for multi-GPU), and refactoring to turn it into a library like cuBLAS is

a. too much effort
b. probably not worth it.

Again, following @eniko's original thread, it's really not that hard to roll your own, and probably less time consuming than trying to wrangle your way through an API that may or may not fit your needs.

6/

Question for the #rstats crowd. Do you disable hyperthreads when you run analyses in R with a multithreaded version of #blas e.g. #openblas #mkl etc ?

Question for the #rstats crowd. Do you disable hyperthreads when you run analyses in R with a multithreaded version of #blas e.g. #openblas #mkl etc ?

Question for the #rstats crowd. Do you disable hyperthreads when you run analyses in R with a multithreaded version of #blas e.g. #openblas #mkl etc ?

5 of these methods can leverage multithreaded (MT) #BLAS with a sweet spot ~ 6 threads for the 40% of the time spent in MT regions. E5-2697 has 36/72 (physical/logical) cores, so the avg case scenario is one in which 0.4x3x6 cores +2 (serial methods) tie up ~ 9.2 cores ~13% of the 72 logical cores. So far the back of envelope calculation, i.e. if I run 5 out of the 2100 design points in parallel, I will stay within 15% of resource use is holding rather well! #benchmarking #hpc #rstats

5 of these methods can leverage multithreaded (MT) #BLAS with a sweet spot ~ 6 threads for the 40% of the time spent in MT regions. E5-2697 has 36/72 (physical/logical) cores, so the avg case scenario is one in which 0.4x3x6 cores +2 (serial methods) tie up ~ 9.2 cores ~13% of the 72 logical cores. So far the back of envelope calculation, i.e. if I run 5 out of the 2100 design points in parallel, I will stay within 15% of resource use is holding rather well! #benchmarking #hpc #rstats

5 of these methods can leverage multithreaded (MT) #BLAS with a sweet spot ~ 6 threads for the 40% of the time spent in MT regions. E5-2697 has 36/72 (physical/logical) cores, so the avg case scenario is one in which 0.4x3x6 cores +2 (serial methods) tie up ~ 9.2 cores ~13% of the 72 logical cores