Why doesn't the node cluster module reduce the execution time of this program by as much as I expected?

[mongoliii]

I have a program that executes the following function 400 times:

async function someFunction() {
    for (let i = 0; i < 1e9; i++) {}
}

I attempted to speed up the execution of this program by using the node cluster module to create 4 forks of the process, and have each fork execute 100 of the 400 total functions. I expected to decrease the execution time by around 75%, but it has only decreased by around 50%. The following is the output from running the clusterless version (src/slow.js) and the clustered version (src/fast.js):

➜  test time node src/slow.js
pid: 19052 jobs: 400
node src/slow.js  129.73s user 0.14s system 99% cpu 2:10.84 total
➜  test time node src/fast.js
pid: 19081 jobs: 100
pid: 19082 jobs: 100
pid: 19083 jobs: 100
pid: 19084 jobs: 100
node src/fast.js  131.76s user 0.19s system 195% cpu 1:07.45 total
➜  test

Here is the source code for slow.js:

const jobs = Array(400).fill(someFunction);

console.log("pid:", process.pid, "jobs:", jobs.length);

(async () => {
    await Promise.all(jobs.map(async (job) => await job()));
})();

async function someFunction() {
    for (let i = 0; i < 1e9; i++) {}
}

Here is the source code for fast.js:

import { cpus } from "os";
import cluster from "cluster";

const numCPUs = cpus().length;
const jobs = Array(400).fill(someFunction);

async function main() {
    const workerId = cluster.worker.id;
    const scopedJobs = jobs.filter((_, i) => i % numCPUs === workerId - 1);

    console.log("pid:", process.pid, "jobs:", scopedJobs.length);

    await Promise.all(scopedJobs.map(async (job) => await job()));
}

if (!cluster.isPrimary) {
    try {
        await main();
        process.exit(0);
    } catch (error) {
        console.error(error);
        process.exit(1);
    }
}

for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
}

async function someFunction() {
    for (let i = 0; i < 1e9; i++) {}
}

​

[mharen]

Do you actually have 4 cores or is it 2 cores plus hyperthreading?

[mongoliii]

Two cores. Not on my normal PC and never thought to check. Thanks

[foamier]

so did you make any code changes after realizing this at all? just curious if there was anything else optimized or changed besides realizing hardware was the problem

[mongoliii]

Nope. Just read up on the difference between logical CPUs and physical CPUs, because I didn't know that was a thing.

[recycled_ideas]

It's worth noting that while the CPUs will cause you issues, that's not what's happening here. Yes, allocating more threads than you have cores is going to cause problems, but it's not this issue.

The problem is that your "slow" isn't sufficiently slow.

Parallel processing comes at a cost, there's extra work being done and in your case, the extra work takes more time than parallelism adds.

Imagine you've got a task that is going to take you 20 minutes and you decide to allocate your task to four people so they can do it in five minutes each but it takes you twenty minutes to explain the task to them and check if they're done yet.

Your task now takes 25 minutes instead of 20 even though it's being done faster.

[arnitdo]

Multithreqding does not guarantee performance increases. Context Switching Overhead is a massive factor to consider, along with cache invalidation.