mclapply is a parallelized version of
it returns a list of the same length as
X, each element of
which is the result of applying
FUN to the corresponding
It relies on forking and hence is not available on Windows unless
mc.cores = 1.
mcmapply is a parallelized version of
mcMap corresponds to
1 2 3 4 5 6 7 8 9 10 11 12
mclapply(X, FUN, ..., mc.preschedule = TRUE, mc.set.seed = TRUE, mc.silent = FALSE, mc.cores = getOption("mc.cores", 2L), mc.cleanup = TRUE, mc.allow.recursive = TRUE, affinity.list = NULL) mcmapply(FUN, ..., MoreArgs = NULL, SIMPLIFY = TRUE, USE.NAMES = TRUE, mc.preschedule = TRUE, mc.set.seed = TRUE, mc.silent = FALSE, mc.cores = getOption("mc.cores", 2L), mc.cleanup = TRUE, affinity.list = NULL) mcMap(f, ...)
a vector (atomic or list) or an expressions vector. Other
objects (including classed objects) will be coerced by
the function to be applied to (
the function to be applied in parallel to
if set to
if set to
The number of cores to use, i.e. at most how many child processes will be run simultaneously. The option is initialized from environment variable MC_CORES if set. Must be at least one, and parallelization requires at least two cores.
if set to
Unless true, calling
a vector (atomic or list) containing the CPU
affinity mask for each element of
mclapply is a parallelized version of
mc.cores > 1: for
mc.cores == 1 (and the
NULL) it simply calls
By default (
mc.preschedule = TRUE) the input
X is split
into as many parts as there are cores (currently the values are spread
across the cores sequentially, i.e. first value to core 1,
second to core 2, ... (core + 1)-th value to core 1 etc.) and then
one process is forked to each core and the results are collected.
Without prescheduling, a separate job is forked for each value of
X. To ensure that no more than
mc.cores jobs are
running at once, once that number has been forked the master process
waits for a child to complete before the next fork.
Due to the parallel nature of the execution random numbers are not
sequential (in the random number sequence) as they would be when using
lapply. They are sequential for each forked process, but not
all jobs as a whole. See
mcparallel or the package's
vignette for ways to make the results reproducible with
mc.preschedule = TRUE.
Note: the number of file descriptors (and processes) is usually
limited by the operating system, so you may have trouble using more
than 100 cores or so (see
ulimit -n or similar in your OS
documentation) unless you raise the limit of permissible open file
descriptors (fork will fail with error
"unable to create a pipe").
Prior to R 3.4.0 and on a 32-bit platform, the serialized result from each forked process is limited to 2^31 - 1 bytes. (Returning very large results via serialization is inefficient and should be avoided.)
affinity.list can be used to run elements of
specific CPUs. This can be helpful, if elements of
X have a
high variance of completion time or if the hardware architecture is
heterogeneous. It also enables the development of scheduling
strategies for optimizing the overall runtime of parallel jobs. If
affinity.list is set, the
mc.core parameter is replaced
with the number of CPU ids used in the affinity masks.
mclapply, a list of the same length as
X and named
mcmapply, a list, vector or array: see
mcMap, a list.
Each forked process runs its job inside
try(..., silent = TRUE)
so if errors occur they will be stored as class
objects in the return value and a warning will be given. Note that
the job will typically involve more than one value of
"try-error" object will be returned for all the values
involved in the failure, even if not all of them failed.
It is strongly discouraged to use these functions in GUI or embedded environments, because it leads to several processes sharing the same GUI which will likely cause chaos (and possibly crashes). Child processes should never use on-screen graphics devices.
Some precautions have been taken to make this usable in
R.app on macOS, but users of third-party front-ends
should consult their documentation.
Note that tcltk counts as a GUI for these purposes since
Tcl runs an event loop. That event loop
is inhibited in a child process but there could still be problems with
Tk graphical connections.
Simon Urbanek and R Core.
affinity.list feature by Helena Kotthaus and Andreas Lang,
Derived from the multicore package formerly on CRAN.
simplify2array for results like
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
simplify2array(mclapply(rep(4, 5), rnorm)) # use the same random numbers for all values set.seed(1) simplify2array(mclapply(rep(4, 5), rnorm, mc.preschedule = FALSE, mc.set.seed = FALSE)) ## Contrast this with the examples for clusterCall library(boot) cd4.rg <- function(data, mle) MASS::mvrnorm(nrow(data), mle$m, mle$v) cd4.mle <- list(m = colMeans(cd4), v = var(cd4)) mc <- getOption("mc.cores", 2) run1 <- function(...) boot(cd4, corr, R = 500, sim = "parametric", ran.gen = cd4.rg, mle = cd4.mle) ## To make this reproducible: set.seed(123, "L'Ecuyer") res <- mclapply(seq_len(mc), run1) cd4.boot <- do.call(c, res) boot.ci(cd4.boot, type = c("norm", "basic", "perc"), conf = 0.9, h = atanh, hinv = tanh) ## Usage of the affinity.list parameter A <- runif(2500000,0,100) B <- runif(2500000,0,100) C <- runif(5000000,0,100) first <- function(i) head(sort(i), n = 1) # Restict all elements of X to run on CPU 1 and 2 affL <- list(c(1,2), c(1,2), c(1,2)) mclapply(list(A, A, A), first, mc.preschedule = FALSE, affinity.list = affL) # Completion times are assumed to have a high variance # To optimize the overall execution time elements of X are scheduled to suitable CPUs # Assuming that the runtime for C is as long as the runtime of A plus B # mapping: A to 1 , B to 1, C to 2 X <- list(A, B, C) affL <- c(1, 1, 2) mclapply(X, first, mc.preschedule = FALSE, affinity.list = affL)
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.