Parallel Computing in R Exercises: 20 Practice Problems

total_cores <- parallel::detectCores()
ex_1_1 <- c(total = total_cores, workers = total_cores - 1L)
ex_1_1
#> total workers
#>     8       7

Explanation: detectCores() returns the number of logical CPUs reported by the OS, which on modern Intel and AMD chips includes hyperthreads. The minus-one idiom keeps the machine responsive: if you grab every core, the OS thread that scheduled R itself competes with your workers and overall throughput often drops. Use detectCores(logical = FALSE) if you want physical cores only, which can help when the workload is CPU-bound rather than IO-bound.

ex_1_2 <- parallel::mclapply(mtcars, mean, mc.cores = 2)
ex_1_2[1:2]
#> $mpg
#> [1] 20.09062
#>
#> $cyl
#> [1] 6.1875

Explanation: mclapply() is a drop-in parallel replacement for lapply() on Linux and macOS, using fork() to copy the parent process. Forking is fast (copy-on-write memory) but does not exist on Windows, where the function falls back to sequential execution with a warning suppressed. For cross-platform parallel apply, prefer future.apply::future_lapply() or parLapply() with an explicit cluster.

run_squared <- function(n) {
  cl <- parallel::makeCluster(2)
  on.exit(parallel::stopCluster(cl))
  unlist(parallel::parLapply(cl, seq_len(n), function(x) x^2))
}
ex_1_3 <- run_squared(6)
ex_1_3
#> [1]  1  4  9 16 25 36

Explanation: PSOCK clusters spawn fresh R sessions and communicate over sockets, so they work on every platform including Windows. The on.exit() guard is the single most important pattern in cluster code: without it, a thrown error inside parLapply() leaves orphaned R processes that lock files, hold ports, and bleed memory. Wrapping the cluster lifecycle in a function gives the call site a single tidy entry point.

cl <- parallel::makeCluster(2)
on.exit(parallel::stopCluster(cl))
multiplier <- 10
parallel::clusterExport(cl, "multiplier")
invisible(parallel::clusterEvalQ(cl, library(dplyr)))
ex_1_4 <- parallel::parSapply(cl, 1:5, function(x) multiplier * x)
parallel::stopCluster(cl)
ex_1_4
#> [1] 10 20 30 40 50

Explanation: clusterExport() copies named objects from the parent environment into each worker, and clusterEvalQ() runs an arbitrary expression on each worker (commonly library() calls). Forgetting either is the most common bug: the parent works but workers throw "object not found" or "could not find function". The future framework removes this friction by detecting needed globals automatically, which is why most modern code uses future and furrr instead of raw PSOCK.

future::plan(future::sequential)
f <- future::future({ Sys.sleep(0.1); sqrt(144) })
ex_2_1 <- future::value(f)
ex_2_1
#> [1] 12

Explanation: A future is a placeholder for a value that may be computed elsewhere or later. future() schedules the work and returns immediately; value() blocks until the result is ready. With plan(sequential) everything runs in the current process so timings are not faster, but the API is identical to multisession or multicore plans, which means you can prototype on sequential, then change one line to scale out without touching the rest of your code.

future::plan(future::multisession, workers = 2)
ex_2_2 <- unlist(future.apply::future_lapply(1:8, sqrt))
ex_2_2
#> [1] 1.000000 1.414214 1.732051 2.000000 2.236068 2.449490 2.645751 2.828427
future::plan(future::sequential)

Explanation: multisession spawns persistent background R sessions (built on PSOCK) and reuses them across calls, so the per-call overhead is paid once. future_lapply() is the drop-in replacement for lapply() and handles globals automatically: it scans the function body and ships needed variables to workers without an explicit clusterExport(). Always reset to plan(sequential) at the end of an interactive script so background workers do not linger.

if (future::supportsMulticore()) {
  future::plan(future::multicore, workers = 2)
} else {
  future::plan(future::multisession, workers = 2)
}
ex_2_3 <- class(future::plan())[1]
ex_2_3
#> [1] "multisession"
future::plan(future::sequential)

Explanation: Fork-based parallelism is faster to start up (no R session spawn, no global serialization) but is unsafe inside RStudio and absent on Windows. supportsMulticore() is a single-line portability check that returns FALSE on Windows or inside the RStudio GUI, so the same code can ship to a teammate on a different OS without breaking. The chosen plan class is returned by class(plan()) and is useful for logging which mode actually ran.

future::plan(future::multisession, workers = 3)
fs <- list(
  future::future({ Sys.sleep(0.5); 1 }),
  future::future({ Sys.sleep(0.05); 2 }),
  future::future({ Sys.sleep(0.5); 3 })
)
Sys.sleep(0.2)
ex_2_4 <- vapply(fs, future::resolved, logical(1))
ex_2_4
#> [1] FALSE  TRUE FALSE
future::plan(future::sequential)

Explanation: resolved() is non-blocking: it asks "is this future done yet?" and returns immediately, unlike value() which waits. This is the key building block for progress bars (progressr), throttled queues, and dashboards that need to poll multiple long-running jobs. The pattern generalizes: launch many futures, store them in a list, then either vapply(fs, resolved, ...) to poll or future::value(fs) to block on all of them.

future::plan(future::multisession, workers = 2)
ex_3_1 <- furrr::future_map_dbl(1:6, function(x) x^2)
ex_3_1
#> [1]  1  4  9 16 25 36
future::plan(future::sequential)

Explanation: The future_map_*() family mirrors purrr::map_*(): future_map() returns a list, future_map_dbl() enforces a numeric vector, future_map_chr() a character vector, and so on. The type-stable variants fail loudly if a worker returns the wrong type, which catches bugs (NA propagation, NULL returns) faster than a permissive future_map() plus a manual unlist(). Whenever you know the output type, prefer the typed variant.

future::plan(future::multisession, workers = 2)
ex_3_2 <- furrr::future_map_dfr(
  split(mtcars, mtcars$cyl),
  function(d) tibble::tibble(mean_mpg = mean(d$mpg), mean_hp = mean(d$hp)),
  .id = "cyl"
)
ex_3_2
#> # A tibble: 3 x 3
#>   cyl   mean_mpg mean_hp
#>   <chr>    <dbl>   <dbl>
#> 1 4         26.7    82.6
#> 2 6         19.7   122.
#> 3 8         15.1   209.
future::plan(future::sequential)

Explanation: future_map_dfr() is the parallel equivalent of purrr::map_dfr() and is the right pattern for split-apply-combine where each group fits comfortably in a worker. The .id argument turns the names of the input list into a column, which keeps the group key in the result. For very fine-grained groups (thousands of small chunks), the per-chunk serialization overhead can eat the parallel gains; profile first.

future::plan(future::multisession, workers = 2)
draws <- furrr::future_map(
  1:3,
  function(i) rnorm(100),
  .options = furrr::furrr_options(seed = 123)
)
ex_3_3 <- vapply(draws, mean, numeric(1))
ex_3_3
#> [1] -0.05768771  0.07730672 -0.03862729
future::plan(future::sequential)

Explanation: Naive set.seed() does NOT make parallel code reproducible: each worker has its own RNG state, and which iteration lands on which worker depends on load balancing. furrr_options(seed = 123) builds a parallel-safe L'Ecuyer-CMRG stream so iteration i always gets the same sub-stream regardless of worker count. Forgetting this option is the most common reproducibility bug in parallel R code; the gate seed = TRUE (without an integer) auto-generates a stream you can record for later replay.

future::plan(future::multisession, workers = 2)
args_df <- tibble::tibble(x = 1:4, y = c(10, 20, 30, 40))
ex_3_4 <- furrr::future_pmap_dbl(args_df, function(x, y) x * y)
ex_3_4
#> [1]  10  40  90 160
future::plan(future::sequential)

Explanation: future_pmap_dbl() walks over a list of equal-length vectors (or a tibble's rows) and calls the supplied function with each row's columns as named arguments. It is the parallel equivalent of purrr::pmap_dbl() and is the cleanest way to parameter-sweep across two or more inputs without manually building Map() or nested loops. The argument names of the function must match the column names of the tibble.

ex_4_1 <- foreach::foreach(i = 1:5) %do% { i^2 }
ex_4_1[1:2]
#> [[1]]
#> [1] 1
#>
#> [[2]]
#> [1] 4

Explanation: foreach is a for-loop replacement that always returns its values rather than relying on side effects. %do% runs sequentially; %dopar% runs in parallel against whatever backend is registered. The default combiner returns a list, but .combine = c, .combine = "+", or .combine = rbind are common. Getting the sequential version right first means the parallel switch is a one-character change.

cl <- parallel::makeCluster(2)
doParallel::registerDoParallel(cl)
on.exit(parallel::stopCluster(cl))
ex_4_2 <- foreach::foreach(i = 1:10, .combine = "+") %dopar% {
  i^2
}
parallel::stopCluster(cl)
ex_4_2
#> [1] 385

Explanation: .combine = "+" calls Reduce("+", results) so the workers can each compute partial squares and the reducer adds them, which avoids materializing a length-10 vector in the parent. Common combiners: c for a flat vector, cbind/rbind for matrices, data.frame for tabular output (slow on big data, prefer dplyr::bind_rows() afterward). The registerDoParallel() plus stopCluster() pair is the boilerplate; the modern alternative is doFuture::registerDoFuture() to drive foreach with whatever future plan is active.

cl <- parallel::makeCluster(2)
doParallel::registerDoParallel(cl)
on.exit(parallel::stopCluster(cl))
ex_4_3 <- foreach::foreach(i = 1:5, .combine = rbind,
                           .options.RNG = 42) %dorng% {
  rnorm(3)
}
attr(ex_4_3, "rng") <- NULL  # drop the rng attribute for printing
rownames(ex_4_3) <- NULL
parallel::stopCluster(cl)
ex_4_3

Explanation: %dorng% from the doRNG package replaces %dopar% and threads a parallel-safe L'Ecuyer-CMRG stream through every iteration. The .options.RNG = 42 argument seeds that stream so the same seed produces the same numbers regardless of how many workers handle each iteration. Plain %dopar% plus set.seed() is NOT reproducible because the timing of worker hand-offs is non-deterministic; reach for %dorng% whenever results need to match across runs.

future::plan(future::multisession, workers = 2)
ex_5_1 <- furrr::future_map_dbl(
  seq_len(1000),
  function(i) median(sample(mtcars$mpg, replace = TRUE)),
  .options = furrr::furrr_options(seed = 7)
)
summary(ex_5_1)
#>    Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
#>   15.00   18.50   19.20   19.27   20.10   24.40
future::plan(future::sequential)

Explanation: Bootstrap is the textbook parallel workload: 1,000 independent resamples with no cross-iteration state. The seed option threads a reproducible RNG stream so a 5-worker run and a 16-worker run produce the same 1,000 medians in the same positions. For real production bootstraps, 1,000 iterations is a starting point; precision of the standard error scales with sqrt(B), so 10,000 is a common target when CIs need a third significant digit.

future::plan(future::multisession, workers = 2)
set.seed(1)
folds <- split(sample(seq_len(nrow(mtcars))), rep(1:5, length.out = nrow(mtcars)))
ex_5_2 <- furrr::future_map_dbl(
  folds,
  function(test_idx) {
    train <- mtcars[-test_idx, , drop = FALSE]
    test  <- mtcars[ test_idx, , drop = FALSE]
    fit   <- lm(mpg ~ wt + hp, data = train)
    mean((predict(fit, test) - test$mpg)^2)
  },
  .options = furrr::furrr_options(seed = 1)
)
ex_5_2
future::plan(future::sequential)

Explanation: Each fold is independent so cross-validation parallelizes perfectly. Two seed touch points matter: set.seed(1) before sample() controls how rows are assigned to folds (a serial operation), and furrr_options(seed = 1) controls any random calls inside the worker function. For pure least-squares regression there are no random calls in the fit, but the option is still wise habit so the same code stays reproducible when you swap in random forest or boosting.

future::plan(future::multisession, workers = 2)
batch_pi <- function(n) {
  x <- runif(n, -1, 1)
  y <- runif(n, -1, 1)
  4 * mean(x^2 + y^2 <= 1)
}
estimates <- furrr::future_map_dbl(
  rep(1e5, 4),
  batch_pi,
  .options = furrr::furrr_options(seed = 99)
)
ex_5_3 <- mean(estimates)
ex_5_3
#> [1] 3.141758
future::plan(future::sequential)

Explanation: Monte Carlo with independent batches is the canonical "embarrassingly parallel" workload: zero cross-batch communication, perfect linear speedup until disk or RAM bottlenecks kick in. Computing one mean of the per-batch estimates is mathematically equivalent to one large estimate when batch sizes are equal, and it gives you a free per-batch standard error: sd(estimates) / sqrt(length(estimates)) quantifies how much pi is wandering between batches.

future::plan(future::multisession, workers = 2)
d <- ggplot2::diamonds
d$carat_bin <- cut(d$carat, breaks = c(0, 0.5, 1, 1.5, 2, 3, 6))
ex_5_4 <- furrr::future_map_dfr(
  split(d, d$carat_bin),
  function(chunk) tibble::tibble(median_price = median(chunk$price)),
  .id = "carat_bin"
)
ex_5_4
future::plan(future::sequential)

Explanation: Splitting before mapping is fine for a handful of groups, but for hundreds of groups the serialization cost (each chunk is shipped to a worker) dominates. The rule of thumb: each chunk should keep a worker busy for at least 50 to 100 milliseconds, otherwise stay sequential or batch groups together. For very many tiny groups, plain dplyr::summarise() or data.table is faster than any parallel approach because it stays single-threaded but vectorized.

future::plan(future::multisession, workers = 2)
ex_5_5 <- furrr::future_map_dfr(
  c(4, 6, 8),
  function(k) {
    sub <- mtcars[, c(1, 2:(k + 1))]
    fit <- lm(mpg ~ ., data = sub)
    tibble::tibble(k = k, aic = AIC(fit))
  }
)
ex_5_5
future::plan(future::sequential)

Explanation: Hyperparameter sweeps are the second canonical parallel workload after Monte Carlo: each configuration is independent and fits a complete model. For a real sweep with thousands of configurations, prefer tune (tidymodels) or mlr3 which add resume-on-failure, progress bars, and intelligent search; for a quick custom sweep with under a thousand cells, future_map_dfr() plus a small parameter grid is faster to write and good enough.

future::plan(future::multisession, workers = 2)
guarded_sqrt <- purrr::safely(function(x) {
  if (x < 0) stop("negative input")
  sqrt(x)
})
ex_6_1 <- furrr::future_map(c(4, -1, 9, -2, 16), guarded_sqrt)
purrr::map(ex_6_1, "result")
#> $`1`
#> [1] 2
#>
#> $`2`
#> NULL
#>
#> $`3`
#> [1] 3
future::plan(future::sequential)

Explanation: safely() wraps a function so it returns a list with two slots: result (or NULL on error) and error (or NULL on success). In parallel code this is the difference between a job that finishes with partial output and a job that crashes on iteration 47 of 10,000. The sibling purrr::possibly(f, otherwise = NA) is simpler when you just want a sentinel value, while safely() keeps the error messages for post-mortem inspection.

future::plan(future::multisession, workers = 2)
work <- function(x) { Sys.sleep(0.1); x^2 }
bm <- microbenchmark::microbenchmark(
  sequential = lapply(1:4, work),
  parallel   = future.apply::future_lapply(1:4, work),
  times = 3
)
medians <- aggregate(time ~ expr, data = bm, FUN = median)
ex_6_2 <- setNames(medians$time / 1e6, medians$expr)
ex_6_2
future::plan(future::sequential)

Explanation: Parallel speedup is bounded by Amdahl's law: only the iterated portion benefits, while serialization (shipping inputs to workers, receiving outputs) is fixed overhead. The 0.1-second sleep makes the iteration heavy enough that two workers roughly halve the wall time. If you halve the sleep to 0.001 seconds, the overhead dominates and multisession is SLOWER than lapply(). The "should I parallelize?" question is empirical: benchmark first, then decide.

future::plan(future::multisession, workers = 2)
invisible(furrr::future_map(1:2, sqrt))
future::plan(future::sequential)
ex_6_3 <- class(future::plan())[1]
ex_6_3
#> [1] "sequential"

Explanation: multisession workers persist across calls so subsequent jobs avoid the spawn overhead, but they keep R processes (and their memory) alive in the background until the script ends or you explicitly reset the plan. Setting plan(sequential) is the documented teardown idiom; it sends a shutdown signal to the worker pool. Leaving stale workers around is a common cause of "my laptop is hot for no reason" tickets and shows up as orphaned Rscript processes in top.