"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes: >> If the ABI of the variants is really the same, then one can flip the >> variable and "make replace OLDNAME=3D" with the new openblas. Or just >> pkg_delete -f and install the ne one. > > The ABI is the same, as it follows an established standard that has > several implementations. There are specialties like using OpenMP or > phthreads under the hood. But the ABI symbols are the same plus some > non-standard extensions (OpenBLAS function for setting thread number). > Basically everything should be able to build with any variant of BLAS, > but unless we have extra magic that hides the non-standard symbols > (like Debian's libblas.so wrappers, AFAIK), things will need a rebuild > to ensure that the new BLAS is correctly used. I may be being pedantic, but if you have to recompile the ABI is not actually the same. Same ABI means you can swap out the library and it's always ok, by definition. >> If they are made parallel installable, sort of like guile20 and guile22, >> then there can be a per-package variable to link against various >> versions. > > So, a normal thing would be to add BLAS_DEFAULT and possibly > BLAS_ACCEPTED to packages if we determine that some are incompatible > with differing BLAS? I only imagine that being the case when we did > not yet get around patching a build script that has -lblas hardcoded > where we want to insert -lopenblas. Yes, that's the general idea. As far as having -lblas hardcoded, there really needs to be a scheme to use blas.pc which is brought into visisbility by the bl3 file, and have that drive the names and paths. > I wonder how much logic of the KRB5 stuff applies here. Can packages > override KRB5_DEFAULT by setting KRB5_TYPE? But not in mk.conf > per-package, right? I'm not sure. But we do have a notion of per-package variables to control things like this, if multiple of the alternatives can be installed and not conflict. > As the libraries are not conflicting, per the last agreement Jason and > I had, things can be installed in parallel, with differing names of the > libraries, but the same symbols. Two thoughts: You say library names not conflicting, but I wonder if you can assert that this is always true and always will be true for any pair of blas-like things. forks tend to only sometimes change names. If you really can't guarantee separate names, and I don't think you can that leads to /usr/pkg/fooblas/lib?blas.so, and if fooblas and barblas have the same name, it's ok. It also allows you to put in /usr/pkg/fooblas/lib/pkgconfig/blas.pc and force that for every one, and to have the logic to find blas use that, and patch all depending packages to find the pc file. With the same symbols, you really cannot link different blas implementations in the same program. So you are in trouble if there are libraries that use blas, and other packages use those. Is that going to be a problem? >> However, if there is a library that links against OpenBLAS, >> and then something else links against that, [=E2=80=A6] > > Yes. This is the mess I want to avoid. I would like all pkgsrc packages > using one BLAS, but still see value in providing the others to users to presumably you mean in any one consistent build. > use in their own programs. We install pkgsrc as a platform for the > actual end-user applications. Some of them are part of pkgsrc, some are > just the code written by scientists themselves. If pkgsrc uses serial > OpenBLAS, they should be able to knowingly link against the > OpenMP-parallel version and vice versa. They can even do LD_PRELOAD and > run pkgsrc applications with a different BLAS lib from pkgsrc. The user > shall have all power. LD_PRELOAD only works if the ABI really is the same. >> Without understanding the details, it seems that it is basically a bug >> that multiple variants exist. But I realize coping with bugs is >> sometimes easier than fixing them. > > It's not a bug, it's a feature;-) Different BLAS version exist because > they are optimized to different degrees on differing hardware. > Historically, a vendor of a HPC system delivered a compiler, MPI, and BLAS > that were all tuned to the machine at hand. Scientists came along and > built their code using these provided vendor tools to get optimal > performance. Well I meeant not bug that they exist at all, but bug that for a given system there isn't a straightforward choice of a single right answer. So it's a bug that it isn't run-time all magically in one library that does the rigth thing. But I see why that's too hard, and that demanding that this problem be solved is not a useful path forward. > Machines are a lot less special now, so that you have a vast majority > of HPC installations running more general-purpose BLAS implementations. > There is still special stuff around in the network department, that is > why you will use Cray's MPI implementation when on a Cray system. But > also on a bog-standard cluster, you can buy the Intel compilers with > the MKL, which is usually a bit ahead in performance compared to a GCC > with a free BLAS implementation. The gap closed considerably with newer > GCCs and with OpenBLAS being tuned for farily recent Intel CPUs. I am > not sure what the best is on AMD CPUs. Or ARM. Or MIPS (Longsoon). > There still is the approach of ATLAS to build an optimized BLAS for any > machine by measuring variants during build, but it is outperformed by > the hand-tuned code of OpenBLAS. Performance is the reason to make > the software (more) messy. OK, but that sounds like an argument for choosing a BLAS tune to the arch, system wide. >> I see in wip openblas-devel and OpenBLAS, and they seem to be the same >> version. Where are the various versions being considered to be >> switched? > > Jason and I were discussing on which one of the two to use as a > starting point for math/openblas. Wip/openblas-devel is the FreeBSD > approach with differing variants of the OpenBLAS libraries being > installed next to each other (serial, parallel-pthread/openmp). > Wip/OpenBLAS is the package I currently use, with a build-time choice > on exactly one variant to install (plus auxilliary files that only make > sense when they match that variant). > > The other BLAS implementations are math/blas (with math/lapack) and > wip/atlas. Thanks. I guess after reading all this, it's hard to come down with a view. It seems nicer to be able to install multiple things at once in parallel, and let depending packages choose, but it's also harder to make it all work. So I guess I feel fine either way (as a guardian of pkgsrc cleanliness) if you two want to do the work either way. I think the big thing is that building things without options should do somethhing sane like install one version and have everything use it and be sure that it gets the right answers.
Attachment:
signature.asc
Description: PGP signature