[I found I hadn't sent this earlier, as I should have.] > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > == Summary == > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper > library, which will set OpenBLAS as system-wide default backend, and > at the same time will provide a proper switching mechanism that > currently Fedora lacks. > I oppose this (in favour of a different approach) from experience in research computing system management, general support, and implementation. It doesn't solve any problem I (have) had, as far as I can tell, and looks as if it produces more. The licence seems to me to rule it out a priori. The proposal doesn't justify things, including its dismissal of the simple, clean alternative in similar to Debian's, with which I have some experience. (I don't know what the environment modules alternative is, since that's one way of specifying the late binding.) BLAS isn't alone in presenting a substitute interface like that. It works well with a heterogeneous HPC cluster where you want different BLAS implementations on different nodes (think KNL, A64FX). There will be hoops to jump through to get packages to configure when they don't know about the library. If I want to use a library that's not included, I'm in the same position. It's not clear to me a priori what happens if you try to use just BLIS even, given that OpenBLAS' LAPACK implementation isn't the vanilla one, and depends on OpenBLAS as far as I know. The choice of OpenBLAS isn't justified. It's not even obvious that you want the same implementation for serial and multi-threaded as OpenBLAS seems to have had continual problems with threading which BLIS hasn't as far as I know. I expect OpenBLAS is the best serial option on average, at least, but that needs data for different architectures. Profiling is listed as a feature, but I wouldn't want a LA-specific profiler rather than a more general one. (Scorep on el7 currently doesn't do that for want of a suitable clang (or LLVM?) component to do the library wrapping, but it could.) I realize no-one is going to be running Fedora on HPC systems, where this really matters, but presumably it filters down to RHEL, which is looking less and less like a good HPC platform to me. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
