Parallelize 'TSP' functions
Henrik Bengtsson
Source:vignettes/futurize-81-TSP.md
futurize-81-TSP.Rmd
+
=

The futurize package allows you to easily turn
sequential code into parallel code by piping the sequential code to the
futurize() function. Easy!
Introduction
The TSP package provides algorithms for solving the traveling salesperson problem (TSP).
Example:
Example adopted from
help("solve_TSP", package = "TSP"):
library(futurize)
plan(multisession)
library(TSP)
data("USCA50")
methods <- c(
"identity", "random", "nearest_insertion", "cheapest_insertion",
"farthest_insertion", "arbitrary_insertion", "nn", "repetitive_nn",
"two_opt", "sa"
)
## calculate tours - each tour in parallel
tours <- lapply(methods, FUN = function(m) {
solve_TSP(USCA50, rep = 10L, method = m) |> futurize()
})
names(tours) <- methodsThis will parallelize the computations, given that we have set up parallel workers, e.g.
plan(multisession)The built-in multisession backend parallelizes on your
local computer and works on all operating systems. There are other parallel
backends to choose from, including alternatives to parallelize
locally as well as distributed across remote machines, e.g.
plan(future.mirai::mirai_multisession)and
plan(future.batchtools::batchtools_slurm)Without futurize: Manual PSOCK cluster setup
For comparison, here is what it takes to parallelize
solve_TSP() using the parallel and
doParallel packages directly, without
futurize:
library(TSP)
library(parallel)
library(doParallel)
data("USCA50")
## Set up a PSOCK cluster and register it with foreach
ncpus <- 4L
cl <- makeCluster(ncpus)
registerDoParallel(cl)
## Solve the TSP in parallel via foreach
tour <- solve_TSP(USCA50, method = "nn", rep = 10L)
## Tear down the cluster
stopCluster(cl)
registerDoSEQ() ## reset foreach to sequentialThis requires you to manually create a cluster, register it with
doParallel, and remember to tear it down and reset the
foreach backend when done. If you forget to call
stopCluster(), or if your code errors out before reaching
it, you leak background R processes. You also have to decide upfront how
many CPUs to use and what cluster type to use. Switching to another
parallel backend, e.g. a Slurm cluster, would require a completely
different setup. With futurize, all of this is handled
for you - just pipe to futurize() and control the backend
with plan().