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

Vladimir Dergachev vo|ody@ @end|ng |rom m|nd@pr|ng@com
Mon Mar 21 15:51:45 CET 2022



On Fri, 18 Mar 2022, Simon Urbanek wrote:

> Evan,
>
> honestly, I think your request may be a red herring. Threads typically don't cause memory explosion, because OpenMP threads don't allocate new memory, but uncontrolled forking does. There are many things that are not allowed inside mclapply so that's where I would look. It may be better to look at the root cause first, but for that we would need more details on what you are doing.

Well, actually this is a real issue as glibc has a concept of "memory 
arenas".

When using old-style heap allocation a multi-threaded program would 
have to obtain a lock to the memory allocator - which is a problem in 
object-oriented code that constantly allocates and deallocates small 
pieces of memory.

The solution was to have multiple "arenas" from which memory can be 
allocated and to prevent lock contention. Which works ok when each thread 
uses the same set of objects, but breaks when doing openmp() style 
computation where tasks are assigned to compute threads at random.

The memory footprint of the program can easily grow to the number of 
memory arenas times whatever the footprint was in single-threaded case.

You can force glibc to use heap only with this environment setting:

MALLOC_ARENA_MAX=1

If this happens to make your program slower, this is an indication that 
the program calls memory allocation function too frequently and needs to 
be optimized. This tends to improve both multi-threaded and 
single-threaded performance as memory allocation calls are rather slow 
even without a lock.

best

Vladimir Dergachev

>
> Cheers,
> Simon
>
>



More information about the R-package-devel mailing list