Parallel Computing in R

Reviewed & published by Brayan K

R runs on one core by default, but many tasks are made of independent pieces. Parallel computing spreads those pieces across cores to finish the same work in a fraction of the time.

Part of the free R course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

By the end of this lesson you'll use the parallel package, run loops with foreach and doParallel, reach for future and furrr, and know when parallelism actually pays off.

What You'll Learn in This Lesson

• How to count cores with detectCores()
• How to run tasks with makeCluster() and parLapply()
• Why you must call stopCluster() when done
• How foreach + doParallel parallelize a loop
• How future and furrr unify parallel backends
• When parallelism helps and when it hurts

1️⃣ How Many Cores? detectCores()

The base parallel package ships with R. detectCores() reports how many logical cores you have; leaving one free keeps the rest of the system responsive.

library(parallel)

# How many cores can we use? detectCores() reports logical cores.
detectCores()        # -> e.g. [1] 8

# A polite default: leave one core free for the rest of the system.
n_workers <- detectCores() - 1
n_workers            # -> e.g. [1] 7

2️⃣ Clusters and parLapply()

makeCluster() starts worker processes; parLapply() runs a function over a list across them — a parallel lapply(). Always finish with stopCluster().

library(parallel)

# 1) Start a cluster of worker processes.
cl <- makeCluster(2)

# 2) parLapply() is a parallel lapply() across the workers.
#    Each element is processed independently -- embarrassingly parallel.
slow_square <- function(x) { Sys.sleep(0.1); x^2 }
result <- parLapply(cl, 1:4, slow_square)

# 3) Always release the workers when done.
stopCluster(cl)

unlist(result)       # -> [1]  1  4  9 16

3️⃣ Loops with foreach + doParallel

foreach writes loops that return results; doParallel registers a backend so %dopar% runs iterations in parallel. .combine sets how results are glued together.

library(foreach)
library(doParallel)

# Register a parallel backend, then foreach runs iterations across cores.
cl <- makeCluster(2)
registerDoParallel(cl)

# .combine says HOW to glue the per-iteration results together.
out <- foreach(i = 1:4, .combine = c) %dopar% {
  i^2
}

stopCluster(cl)
out                  # -> [1]  1  4  9 16
# Use %do% instead of %dopar% to run the same loop sequentially.

4️⃣ One API: future & furrr

The future framework lets you choose a backend once with plan(); furrr's future_map() is a parallel drop-in for purrr::map().

library(furrr)

# The future framework gives one API over many backends.
# plan() chooses how to run; multisession uses background R processes.
plan(multisession, workers = 2)

# future_map() is a parallel drop-in for purrr::map().
result <- future_map_dbl(1:4, ~ .x^2)

plan(sequential)     # reset to normal afterwards
result               # -> [1]  1  4  9 16

Your turn. Fill in the ___ blank, run it, and compare with the expected output.

library(parallel)

# 🎯 YOUR TURN — replace each ___ then run it.

# 1) Start a cluster with 2 workers
cl <- makeCluster(2)

# 2) Run a parallel lapply that cubes each number 1:5
cubes <- parLapply(cl, 1:5, function(x) x^___)   # 👉 replace ___ with 3

# 3) ALWAYS release the workers
stopCluster(cl)

print(unlist(cubes))

# ✅ Expected output:
# [1]   1   8  27  64 125

Mini-Challenge: Parallel Simulation

Use foreach with a parallel backend to run four independent simulations and collect their means. Independent random draws are the textbook embarrassingly parallel task.

# 🎯 MINI-CHALLENGE: parallelize a simulation with foreach.
#
# 1. library(foreach) and library(doParallel).
# 2. makeCluster(2) and registerDoParallel(cl).
# 3. With foreach(i = 1:4, .combine = c) %dopar% { ... },
#    return the mean of rnorm(1000) for each i.
# 4. stopCluster(cl) and print the four means.
#
# ✅ Example output (values near 0, your exact numbers vary):
#    [1]  0.012 -0.008  0.031 -0.015

# your code here

Common Errors (and the fix)

• Forgetting stopCluster() — orphaned workers keep eating memory; always shut the cluster down.
• "object not found" on a worker — workers start fresh; export variables with clusterExport() and load packages with .packages in foreach.
• %dopar% runs sequentially — you forgot to register a backend with registerDoParallel().
• Slower than sequential — the task is too small; the overhead of workers exceeds the savings, so keep it sequential.

Pro Tips

• 💡 Leave a core free: use detectCores() - 1 workers so the system stays responsive.
• 💡 Set parallel seeds: use clusterSetRNGStream() or future's seeding for reproducible random draws.
• 💡 Prefer future for portability: one plan() change switches between laptop and cluster.

📋 Quick Reference — Parallel R

🎉 Lesson Complete!

• ✅ detectCores() reports available cores
• ✅ makeCluster() + parLapply() run tasks in parallel
• ✅ Always stopCluster() to free workers
• ✅ foreach + doParallel parallelize loops
• ✅ future and furrr unify backends; parallelize only expensive, independent work
• ✅ You've reached the end of the R course — congratulations!

Practice quiz

Continue this course

• Previous: Interactive Plots with plotly
• Quick reference: R cheat sheet

Frequently asked questions

What is parallel computing and when does it help in R?

R normally runs on a single CPU core, doing one thing at a time. Parallel computing splits work across multiple cores so several pieces run at once, cutting wall-clock time. It helps most for 'embarrassingly parallel' tasks — jobs made of many independent pieces that do not need to talk to each other, like running the same simulation a thousand times, fitting a model to many subsets, or applying a slow function over a large list. The pieces must be independent; if each step depends on the previous one, there is little to parallelize.

How do the parallel package functions fit together?

The base parallel package gives you the building blocks. detectCores() tells you how many cores you have. makeCluster() starts a set of worker R processes. parLapply() (and friends like parSapply()) ship each element of a list to a worker, run your function, and collect the results — a parallel version of lapply(). When you are finished, stopCluster() shuts the workers down to free memory and processes. A typical pattern is detect, make, parLapply, stop, and forgetting the final stopCluster() leaves orphaned processes behind.

What do foreach, doParallel, and future add?

foreach gives a loop-like syntax that returns results, and with the %dopar% operator it runs iterations in parallel; doParallel registers the cluster as the backend that powers %dopar%. The .combine argument controls how the per-iteration results are stitched together (c, rbind, cbind). The future framework, and furrr built on top of it, take a different angle: you call plan() once to choose a backend (sequential, multisession, multicore, or a cluster) and then future_map() runs purrr-style maps in parallel without changing the rest of your code. future makes switching between sequential and parallel a one-line change.

Why is my parallel code sometimes slower than sequential?

Parallelism is not free. Starting worker processes, loading packages on each one, copying data to them, and collecting results back all take time. For tasks that are already fast, this overhead can exceed the time saved, so the parallel version runs slower. Parallelism pays off when each independent piece does enough work to dwarf the setup cost — heavy simulations, slow model fits, large per-element computations. The fix is to profile first, parallelize the genuinely expensive loops, and keep the number of workers sensible (often cores minus one) rather than maximal.