[R-pkg-devel] Setting OpenMP threads (globally) for an R package

[Viechtbauer, Wolfgang (SP)]

Leaving aside whether this whole discussion is really related to the issue that Evan is facing, just for the record, the appropriate environmental variables for different BLAS implementations are:

For OpenBLAS: OPENBLAS_NUM_THREADS
For BLIS:     BLIS_NUM_THREADS
For MKL:      MKL_NUM_THREADS

For Atlas, the number of threads is predetermined at compile time.

Best,
Wolfgang

>-----Original Message-----
>From: Simon Urbanek [mailto:simon.urbanek using R-project.org]
>Sent: Friday, 18 March, 2022 6:33
>To: Evan Biederstedt
>Cc: Viechtbauer, Wolfgang (SP); R Package Development
>Subject: Re: [R-pkg-devel] Setting OpenMP threads (globally) for an R package
>
>Evan,
>
>> On Mar 18, 2022, at 6:10 PM, Evan Biederstedt <evan.biederstedt using gmail.com>
>wrote:
>>
>> Hi Simon
>>
>> Thank you for the detailed explanations; they're very clear and helpful
>thinking through how to debug this.
>>
>> I think I am still fundamentally confused why `export OMP_NUM_THREADS=1` would
>result in the (desirable) behavior of moderate memory usage.
>>
>> > > Moreover, could you explain how setting the OpenMP global variables e.g.
>`OMP_NUM_THREADS=1` would stop forking? I don't quite follow this.
>> > OpenMP has absolutely nothing to do with this as far as I can tell - that's
>why I was saying that OpenMP is the red herring here.
>>
>> There is some connection to setting  `export OMP_NUM_THREADS=1` before starting
>R, and moderate memory usage; that's all I know.
>
>That's odd. OpenMP itself doesn't allocate memory, so that's why I said it
>shouldn't be related.
>
>> I think Wolfgang might be onto something; the R package uses many Matrix
>operations. I think BLAS/LAPACK libraries read these global variables, no?
>
>Ah, ok, now we're getting closer. The BLAS used by R doesn't use parallelization,
>but if you use a 3rd party BLAS implementation, that's whole another story. Some
>parallel BLAS implementations honor OMP_NUM_THREADS even though it has nothing to
>do with OpenMP in that context as BLAS libraries often use their own
>parallelization methods (i.e., even those that don't use OpenMP often honor it).
>Whether you can fork a given BLAS is really implementation-specific. For example,
>you referenced OpenBLAS which appears to *not* be fork-safe at least according to
>this issue: https://github.com/Homebrew/homebrew-core/issues/75506
>
>But, generally, mixing parallel R and parallel BLAS is a really bad idea so -
>even if the BLAS was magically fork-safe you definitely want to limit the threads
>so that you're not overloading the machine: let's say on 8-core machine if you
>spawn 8 processes with mclapply and each R has BLAS that decided to use 8 cores,
>you end up with 64-core utilization on 8-core machine which will simply grind it
>to a halt. So if you have tasks that use threads, don't use multicore as it's
>pointless and generally unsafe.
>
>You have never provided you sessionInfo() so we can't really help you
>specifically ...
>
>Cheers,
>Simon