[R-sig-hpc] Disabling implicit parallelism of multithreaded BLAS from an R package

[Ei-ji Nakama]

hello,
RhpcBLASctl is a package in the state of having started making it....

Example..
$ R -q
> library(RhpcBLASctl)
> omp_get_max_threads()
[1] 8
> omp_set_num_threads(1)
> omp_get_max_threads()
[1] 1
> blas_get_num_procs()
[1] 4
> blas_set_num_threads(2)
> blas_get_num_procs()
[1] 2
> blas_set_num_threads(get_num_cores())
> blas_get_num_procs()
[1] 4

Its need to think independently because there is no relativity in the
control of OpenMP and BLAS.
If Goto or OpenBLAS is done in the build, the instruction of NO_WARMUP
and NO_AFFINITY might be gentle to the user.


2014-08-13 21:02 GMT+09:00 Scott Ritchie <sritchie73 at gmail.com>:
> Hi again Dirk,
>
> If its just an issue with the particular setup I'm using, I'm happy to
> stick `export OPENBLAS_NUM_THREADS=1` in my bash profile.
>
> Good to know about Goto and MKL. I'd just seen them mentioned in the gcbd
> vignette you suggested I read, so assumed they would have the same issue. I
> had originally hope to just set the relevant environment variables for all
> of them (even if they weren't relevant to the user).
>
> I'll construct a minimal example to use as a test case and send it to the
> mailing list.
>
> Cheers,
>
> Scott
>
>
> On 13 August 2014 21:33, Dirk Eddelbuettel <edd at debian.org> wrote:
>
>>
>> Scott,
>>
>> On 13 August 2014 at 20:08, Scott Ritchie wrote:
>> | Hi Claudia,
>> |
>> | The system I tested it on is running Ubuntu 12.04, so it should
>> | theoretically work.
>>
>> I keep forgetting you run an outdated OS version.  As I recall, the
>> OpenBLAS
>> in that release is older / was lagging.  This may work better on newer
>> ones.
>> Worst case, Consider rebuilding the OpenBLAS package from source on your
>> box to create a
>> local backp. (Been there, done that, need to document the process ...)
>>
>> Do you have a small / simple testcase?
>>
>> | I'd also like a way of disabling implicit parallelism if R has been
>> | compiled with Goto BLAS and MKL, since I assume those users will have the
>> | same problem.
>>
>> You may need to change their APIs...  MKL, as I recall, listen to the same
>> (Intel-given) variable.  GotoBLAS is a dead project which was succeeded by
>> OpenBLAS, so changing Goto may be impossible.
>>
>> Thanks also to Claudia for that reminder. I had forgotten this Linux-only
>> aspect.
>>
>> Cheers, Dirk
>>
>>
>>
>> | On 13 August 2014 18:21, beleites,claudia <claudia.beleites at ipht-jena.de
>> >
>> | wrote:
>> |
>> | > Hi Scott
>> | >
>> | > You may need to contact the developers of openblas about
>> | > openblas_set_num_threads. 2yrs ago when Simon was writing that wrapper
>> it
>> | > was only implemented for Linux. All other is just had a non- working
>> dummy.
>> | >
>> | > Hth
>> | >
>> | > Claudia
>> | >
>> | > --
>> | > Claudia Beleites, Chemist
>> | > Spectroscopy/Imaging
>> | > Leibniz Institute of Photonic Technology
>> | > Albert-Einstein-Str. 9
>> | > 07745 Jena
>> | > Germany
>> | >
>> | > email: claudia.beleites at ipht-jena.de
>> | > phone: +49 3641 206-133
>> | > fax:   +49 2641 206-399
>> | >
>> | >
>> | > ________________________________________
>> | > Von: r-sig-hpc-bounces at r-project.org [r-sig-hpc-bounces at r-project.org
>> ]"
>> | > im Auftrag von "Scott Ritchie [sritchie73 at gmail.com]
>> | > Gesendet: Mittwoch, 13. August 2014 06:40
>> | > An: r-sig-hpc at r-project.org
>> | > Betreff: [R-sig-hpc] Disabling implicit parallelism of multithreaded
>> BLAS
>> | >       from an R package
>> | >
>> | > Hi all,
>> | >
>> | > I'm developing a package in which I explicitly handle parallelism, and
>> in
>> | > each parallel R session, running some SVD calculations through Rcpp +
>> | > Armadillo.
>> | >
>> | > On one of my test machines, R 3.1.0 has been compiled against
>> OpenBLAS, so
>> | > the calls to SVD are implicitly parallel.
>> | >
>> | > I can disable this by exporting the appropriate environment variable
>> before
>> | > calling R (OPENBLAS_NUM_THREADS=1), but I would ideally like to
>> abstract
>> | > that detail away from the user (as some of my intended target audience
>> may
>> | > be biologists without a strong computational background, but
>> nevertheless
>> | > operating on a cluster someone else has set up).
>> | >
>> | > I've tried a couple of things to disable the implicit parallelism
>> without
>> | > any success:
>> | >  - Sys.setenv doesn't have any effect, even on the new R sessions
>> spawned
>> | > through `foreach` with the `doMC` parallel backend (this surprises me,
>> is
>> | > my mental model of parallelism in R correct?)
>> | >  - exporting the environment variables using `cstdlib::putenv` in the
>> C++
>> | > code directly before the call to `svd`.
>> | >  - The solution I found through the r-sig-hpc archives:
>> | > https://stat.ethz.ch/pipermail/r-sig-hpc/2012-July/001432.html.
>> Directly
>> | > calling openblas_set_num_threads(1); in the C++ code has no effect.
>> | >
>> | > I've also tried explicitly disabling BLAS in the hope that Armadillo
>> will
>> | > call the LAPACK routines directly (although I may have done this
>> | > incorrectly) by doing the following:
>> | >  - removing the $(BLAS_LIBS) from the PKG_LIBS variable in the
>> | > Makevars/Makevars.win files
>> | >  - Setting #define ARMA_DONT_USE_BLAS and #define ARMA_DONT_USE_WRAPPER
>> | > before including the <RcppArmadillo.h> header file in my source code.
>> | >
>> | > Ideally I'm looking for a solution that allows me to set the maximum
>> number
>> | > of threads to 1 for all the multithreaded BLAS libraries in my package
>> to
>> | > prevent conflicts between the implicit and explicit parallelism. Is
>> this
>> | > possible?
>> | >
>> | > Regards,
>> | >
>> | > Scott Ritchie
>> | >
>> | >         [[alternative HTML version deleted]]
>> | >
>> | > _______________________________________________
>> | > R-sig-hpc mailing list
>> | > R-sig-hpc at r-project.org
>> | > https://stat.ethz.ch/mailman/listinfo/r-sig-hpc
>> |
>> |       [[alternative HTML version deleted]]
>> |
>> | _______________________________________________
>> | R-sig-hpc mailing list
>> | R-sig-hpc at r-project.org
>> | https://stat.ethz.ch/mailman/listinfo/r-sig-hpc
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>>
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-hpc mailing list
> R-sig-hpc at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-hpc



-- 
Best Regards,
--
EI-JI Nakama  <nakama (a) ki.rim.or.jp>
"\u4e2d\u9593\u6804\u6cbb"  <nakama (a) ki.rim.or.jp>