R SIG Fedora - May 2020 - Changing the BLAS from openblas on a F32 box

On Wed, 27 May 2020 at 21:40, Gavin Simpson <ucfagls at gmail.com>
wrote:
>
> Thanks I?aki, that is exactly what i was looking for, esp the last
> option which I have now configured as an alias for easy remembering.
>
> I can answer the question re USE_LOCKING=1. I think that using both
> those options is required to get thread-safety even if openblas was
> compiled for single thread use. I don't know to what extent Simon has
> engaged with upstream on this etc.
I've seen that there is a brief note about this in the project's wiki.
I agree that a sensible default in any distro would be to build
openblas-serial with USE_LOCKING=1. But I don't understand why there
is no recommendation upstream (or I didn't find it besides the note in
the wiki) and there's no idea about the performance penalty that we
incur doing so. I brought this topic to fedora-devel.
> All I know is that using the openblas shipped with Fedora for R is
> currently a recipe for disaster for the large GAMs we're trying to
> fit. But being able to switch to atlas temporarily is a good
> alternative.
Note that switching to openblas-openmp (libopenblaso.so) should be
thread-safe and will probably get you a better performance than Atlas.
Also, Fedora packages blis (which provides
/lib64/blisblas/libblas.so.3). It seems to be thread-safe should be
more performant than Atlas too.

-- 
I?aki ?car

Thanks (again) I?aki.

There was a typo in my reply above. I should have said: I *can't*
answer the question re USE_LOCKING=1.

Those other suggestions are really helpful too; I really didn't
understand what the difference was (I'm still not clear what the
differences are between say openblas-openmp and openblas-openmp64),
but I did get R to pass mgcv's thread safe test with both
openblas-openmp and blis-openmp, so I have aliased those options for
use too.

Just using blis ( /lib64/blisblas/libblas.so.3 ) was generating a
segfault when running the mgcv test.

Really appreciate the help!

All the best

G

On Wed, 27 May 2020 at 14:09, I?aki Ucar <iucar at fedoraproject.org>
wrote:
>
> On Wed, 27 May 2020 at 21:40, Gavin Simpson <ucfagls at gmail.com>
wrote:
> >
> > Thanks I?aki, that is exactly what i was looking for, esp the last
> > option which I have now configured as an alias for easy remembering.
> >
> > I can answer the question re USE_LOCKING=1. I think that using both
> > those options is required to get thread-safety even if openblas was
> > compiled for single thread use. I don't know to what extent Simon
has
> > engaged with upstream on this etc.
>
> I've seen that there is a brief note about this in the project's
wiki.
> I agree that a sensible default in any distro would be to build
> openblas-serial with USE_LOCKING=1. But I don't understand why there
> is no recommendation upstream (or I didn't find it besides the note in
> the wiki) and there's no idea about the performance penalty that we
> incur doing so. I brought this topic to fedora-devel.
>
> > All I know is that using the openblas shipped with Fedora for R is
> > currently a recipe for disaster for the large GAMs we're trying to
> > fit. But being able to switch to atlas temporarily is a good
> > alternative.
>
> Note that switching to openblas-openmp (libopenblaso.so) should be
> thread-safe and will probably get you a better performance than Atlas.
> Also, Fedora packages blis (which provides
> /lib64/blisblas/libblas.so.3). It seems to be thread-safe should be
> more performant than Atlas too.
>
> --
> I?aki ?car


-- 
Gavin Simpson, PhD [he/him/his]           [t] +1 306 337 8863
? Research Scientist                      [f] +1 306 337 2410
Institute of Environmental               [tw] @ucfagls
  Change & Society                        [w] goo.gl/Zpkdem
University of Regina         [w] www.iecs-uregina.ca
Regina, SK S4S 0A2, Canada               [iD] 0000-0002-9084-8413

? Adjunct Professor, Department of Biology, University of Regina.

On Wed, 27 May 2020 at 23:03, Gavin Simpson <ucfagls at gmail.com>
wrote:
>
> Thanks (again) I?aki.
>
> There was a typo in my reply above. I should have said: I *can't*
> answer the question re USE_LOCKING=1.
:)
> Those other suggestions are really helpful too; I really didn't
> understand what the difference was (I'm still not clear what the
> differences are between say openblas-openmp and openblas-openmp64),
> but I did get R to pass mgcv's thread safe test with both
> openblas-openmp and blis-openmp, so I have aliased those options for
> use too.
Basically, openblas has a number of features that can be enabled or
disabled: 64-bit integer support, threading and parallelization of
certain parts using openmp (as, e.g., data.table does). With the
combination of these features, we end up with many different flavors,
and all these are compiled and sub-packaged separately.

Usually, you want parallelization at the top level calling a serial
version, as mgcv does. Otherwise, you may end up with an "explosion"
of threads that is counterproductive.

-- 
I?aki ?car