doParallel, cluster vs cores

Question

What is the difference between cluster and cores in registerDoParallel when using doParallel package?

Is my understanding correct that on single machine these are interchangeable and I will get same results for :

cl <- makeCluster(4)
registerDoParallel(cl)    

and

registerDoParallel(cores = 4)

The only difference I see that makeCluster() has to be stopped explicitly using stopCluster().

Saintmihiel

Not sure, but I guess you will be physically limited by the number of cores, but not by the number of clusters, i.e. the number of "copies of R running in parallel and communicating over sockets". Of course, clusters might potentially share the same core, depending on the ratio number of clusters / number of cores. – Sept

I tend to agree with @Pascal and that there isn't any difference on a single machine, outside of actually trying out what can be achieved and how things work. If you just want to parallelize some code, then it shouldn't matter either way. – Buoyancy

Answer 1

The behavior of doParallel::registerDoParallel(<numeric>) depends on the operating system, see print(doParallel::registerDoParallel) for details.

On Windows machines,

doParallel::registerDoParallel(4)

effectively does

cl <- makeCluster(4)
doParallel::registerDoParallel(cl)

i.e. it set up four ("PSOCK") workers that run in background R sessions. Then, %dopar% will basically utilize the parallel::parLapply() machinery. With this setup, you do have to worry about global variables and packages being attached on each of the workers.

However, on non-Windows machines,

doParallel::registerDoParallel(4)

the result will be that %dopar% will utilize the parallel::mclapply() machinery, which in turn relies on forked processes. Since forking is used, you don't have to worry about globals and packages.

Archetype

to be clear, why does doParallel::registerDoParallel(4) not do the same as cl <- makeCluster(4, type = "FORK"); registerDoParallel(cl) on unix-likes? It seems to me these should be the same, but the latter is much slower in my use-case. – Fiduciary

If you follow the code, you'll see that doParallel::registerDoParallel() will end up using doParallel:::doParallelMC() on Unix, which uses parallel::mclapply() for it's processing. In contrast, using makeCluster(4, type = "FORK"), or equivalently, parallel::makeForkCluster() sets up a PSOCK cluster of forked workers. When you pass that to doParallel::registerDoParallel() you'll end up using doParallel:::doParallelSNOW(), which relies on the parallel::clusterApplyLB() for processing. So, it's parallel::mclapply() vs parallel::clusterApplyLB(). – Archetype

Answer 2

I think the chosen answer is too general and actually not accurate, since it didn't touch the detail of doParallel package itself. If you read the vignettes, it's actually pretty clear.

The parallel package is essentially a merger of the multicore package, which was written by Simon Urbanek, and the snow package, which was written by Luke Tierney and others. The multicore functionality supports multiple workers only on those operating systems that support the fork system call; this excludes Windows. By default, doParallel uses multicore functionality on Unix-like systems and snow functionality on Windows.

We will use snow-like functionality in this vignette, so we start by loading the package and starting a cluster

To use multicore-like functionality, we would specify the number of cores to use instead

In summary, this is system dependent. Cluster is the more general mode cover all platforms, and cores is only for unix-like system.

To make the interface consistent, the package used same function for these two modes.

> library(doParallel)
> cl <- makeCluster(4)
> registerDoParallel(cl)
> getDoParName()
[1] "doParallelSNOW"

> registerDoParallel(cores=4)
> getDoParName()
[1] "doParallelMC"

Mandie

This should be accepted answer since it answers OP's question directly. – Medieval

Answer 3

Yes, it's right from the software view.

on single machine these are interchangeable and I will get same results.

---

To understand 'cluster' and 'cores' clearly, I suggest thinking from the 'hardware' and 'software' level.

At the hardware level, 'cluster' means network connected machines that can work together by communications such as by socket (Need more init/stop operations as stopCluster you pointed). While 'cores' means several hardware cores in local CPU, and they work together by shared memory typically (don't need to send message explicitly from A to B).

At the software level, sometimes, the boundary of cluster and cores is not that clear. The program can be run locally by cores or remote by cluster, and the high-level software doesn't need to know the details. So, we can mix two modes such as using explicit communication in local as setting cl in one machine, and also can run multicores in each of the remote machines.

---

Back to your question, is setting cl or cores equal?

From the software, it will be the same that the program will be run by the same number of clients/servers and then get the same results.

From the hardware, it may be different. cl means to communicate explicitly and cores to shared memory, but if the high-level software optimized very well. In a local machine, both setting will goes into the same flow. I don't look into doParallel very deep now, so I am not very sure if these two are the same.

But in practice, it is better to specify cores for a single machine and cl for the cluster.

Hope this helps you.

Sapient

This is too general. The OP's question is a specific question about doParallel package, not a general concept question. For this question, it's more about platform implementations, and they are different even for single machine. – Mandie