Repository navigation
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1449 +/- ##
==========================================
+ Coverage 69.72% 69.73% +0.01%
==========================================
Files 6204 6208 +4
Lines 497194 497678 +484
Branches 23430 23454 +24
==========================================
+ Hits 346652 347058 +406
- Misses 150116 150194 +78
Partials 426 426
Continue to review full report in Codecov by Harness.
|
|
This may be none of my business, sorry if so. I note this extends your previous skew-symmetric routines. Are there current LAPACK routines that should be updated to use any of those? |
Hi, As far as the current call structure goes, there are no LAPACK routines calling *skewsbmv other than the test routines. Similarly, the *skewsymv, *skewsyr2, *skewsymm, and *skewsyr2k I submitted previously currently have no callers in LAPACK, but a subsequent set of skew-symmetric LAPACK routines I plan to submit will call them. |
Makes sense. Good luck! |
|
This may be just an old man comment, but it still feels wrong to me that a reference library that has been pretty much officially closed&complete for over 30 years - to the extent that any new functions had to be put into LAPACK as "miscellaneous BLAS-like" instead - is suddenly introducing new symbols. There was limited precedent for GEMMTR as GEMMT was around as a vendor extension, but its addition caused problems nevertheless (I'm not even sure that said vendors have adopted the new name) - and I find it a bit weird to see that circumstance now labeled as the other implementations being "deficient". |
|
I agree. The problem is not the addition but as new symbols go into the binary, their absence is very loud as we experienced when In other words, there is no fallback mechanism to make things gracefully run regular |
|
Arguably the addition as such is problematic as well, if the normative power of a reference implementation is still to be taken seriously - does every other implementation of the BLAS have to scramble to stay conformant to what has inexplicably become a moving target ? |
I'd argue that is up to them whether to "scramble". But I like the idea that BLAS can actually evolve rather than being "stable" (in the special biologist sense of "dead"). Having explicit versions of BLAS, as you already have with LAPACK, and even considering separate releases, would be a way to solve this. |
|
Call it something else, if you want it to be a novel BLAS-like library ? |
|
The versioning and compatibility issues raised in this discussion are indeed an problem. But as far as the skew-symmetric routines in BLAS are concerned, I think there is a need to implement them in the reference library, for the following reasons: a. To maintain a correspondence with the symmetric routines in BLAS. If the symmetric routines are implemented in BLAS while the skew-symmetric ones are placed in LAPACK’s blas-like section, this may hurt structural consistency and may also confuse users who read the code about where to look for them. b. As things stand, third-party high-performance implementations of BLAS are the foundation for high-performance LAPACK. LAPACK’s blas-like routines lack comparable high-performance implementations. If the skew-symmetric BLAS routines are placed in LAPACK’s blas-like section, the subsequent series of LAPACK skew-symmetric routines will miss the opportunity to benefit from high-performance implementations. c. Some users only need skew-symmetric matrix-vector/matrix multiplication or rank-2 update operations, and for them a lightweight BLAS library is sufficient; they should not need to pull in LAPACK. |
|
Adding new functionality is not the problem and I think we all want it to move forward and have these. But not thinking about the consequences after the addition is every vendor's problem once something goes in. Suddenly adding stuff to a calcified library is not without its problems and they need to be communicated thoroughly. Otherwise these issues will be dumped on not just OpenBLAS but also MKL, Accelerate and BLIS and many other vendors commercial or otherwise. |
I believe explicit BLAS versioning (#1446) is a good start on such a communication strategy. One of my other projects (PDL) went through a process a couple of years ago of changing from a huge monolith into more, smaller parts. That was a lot of work, but the maintenance and communication benefits were considerable. Perhaps separate releases of reference-BLAS-plus-CBLAS, and reference-LAPACK-plus-LAPACKE, might be contemplated. |
I can only speak for OpenBLAS (at most), but this is going to affect all other implementations, unless they choose to ignore it (at which point it will probably become a mess for FlexiBLAS to sort out). As far as I'm aware, the original BLAS gained its status as the reference implementation through consultations among interested parties about which fundamental routines should be a part of the library - and similarly, consensus seems to have developed that it was a done thing a few years later. I'm not sure it's entirely warranted to claim this grandfathered reference status for adding new functionality decades later. And even with added BLAS versioning, it is only going to get worse once new LAPACK routines start to make use of the new BLAS functionality - historically (as far as I'm aware), new BLAS-like helpers got put into LAPACK when&where there was a need for them, which also meant that other implementers could update both at the same time if and when they choose to adopt new LAPACK functionality. Now it seems likely that a future Reference-LAPACK will no longer build against any third-party BLAS, or build with reduced functionality only. |
That ship has sailed; Apple Accelerate cannot be used as an optimised BLAS by LAPACK 3.12.1, since 3.12.1 needs |
|
Have a look at the box at the top of the page for the latest and greatest https://developer.apple.com/documentation/accelerate/blas-library about 2026 update. BLAS/LAPACK version inside What we are trying to emphasize is that without a fallback mechanism this is just going to bring features for some users at the expense of every other user if versions start to diverge in particular if a famous library uses these new features. I am not against of change, and typically you would find me in the "let's break it at some point" camp. But this is just too much breakage without any planning. |
Well, Intel MKL only gained Things would be very different if we were talking about a mohawkBLAS or langouBLAS (maybe vibeBLAS or ClaudeBLAS even, going forward) rather than what is still considered the BLAS |
This submission provides subroutines of *skewsbmv (skew-symmetric band matrix-vector multiplication). It is a supplement of existed skew-symmetric blas2 subroutines.