On Fri, 3 Jul 2020 at 13:02, Susi Lehtola <jussilehtola@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, 1 Jul 2020 20:16:36 +0200 > Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote: > > > No, this is exactly the wrong way around. You should use the serial > > > library for code that you want to be running in serial (this way you > > > can get several instances of the program running efficiently), and > > > the pthreads version if you want to run the BLAS/LAPACK regions in > > > parallel (but are somehow opposed to OpenMP!).. > > > > I think I'm more confused than before. :D > > > > > > The question of the default is a hard one. What happens if a > > > > multithreaded application that does not use OpenMP is linked with > > > > the OpenMP build of OpenBLAS? > > > > > > Then you get too much parallellism, i.e. every call to OpenBLAS will > > > launch several threads, and this will naturally ruin your scaling. > > > > So would you say that openblas-serial is the most sensible > > system-wide default? > > THERE SHOULD BE NO SYSTEM-WIDE DEFAULT. > > The thing is that the maintainer needs to be able to pick the correct > flavor. If you use the wrong one, you may seriously handicap > performance. I don't agree, because in many (most?) programs you never know what kind of workload is going to run. E.g., in R, octave... there may be parallelization involved, there are packages using OpenMP... Then, even if there really is a best option for a certain program, the maintainer would need to know, which I don't think is a good assumption (see Jerry's comments in this thread). Even if there is a recommendation from upstream, many times it's not the best option either. > But, if one *needs* a system-wide default, in my opinion it > should be the OpenMP version, since it plays well together with both > sequential and OpenMP parallel programs. Thanks. In my opinion, we need a system-wide default, plus we will be offering the most safe and straightforward way to change the backend. And then, if a particular package really needs a particular flavour and really there are arguments not to allow users to switch it, then an exception could be granted for that package. -- Iñaki Úcar _______________________________________________ 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
