1

If I only have two cores, does parallel only run two processes at a time? I guess I'm still confused about processes, threads, and cores....

5
  • It's like a restaurant where there are many tables (processes) but only 2 waters/waitresses (cores). Only 2 tables at a time can interact with the restaurant. Each time the waiter/waitress needs to deal w/ a diff. table they have to "mentally" context switch to what's relevant to that particular table. tldp.org/LDP/tlk/kernel/processes.html
    – slm
    Commented Feb 11, 2014 at 7:51
  • Process vs. thread? Processes require more overhead than a thread. So when the waiter/waitress greets you, takes your drink order, etc. that would be a "process" interaction. A thread is more of a lightweight interaction. They're walking by and you ask for a refill on your drink would be a thread interaction. ece.ubc.ca/~brucew/ebook/AdvancedLinuxProgramming/…
    – slm
    Commented Feb 11, 2014 at 7:56
  • If you're still confused, or anyone else that happens upon this Q in the future, READ THIS: [Advanced Linux Programming](ece.ubc.ca/~brucew/ebook/AdvancedLinuxProgramming/alp-toc.pdf.
    – slm
    Commented Feb 11, 2014 at 7:59
  • @slm Both links you added point to an "under construction" website. Is there an equivalent of those documents available somewhere ?
    – 3nrique0
    Commented Nov 20, 2019 at 15:38
  • 1
    @3nrique0 they worked 5 yrs ago 8-). I've updated both those comments so they work now.
    – slm
    Commented Nov 20, 2019 at 17:54

1 Answer 1

3

Cores are physical units of computation. You can not get performance beyond the physical capacity of a core. A process in simple terms is a logical unit of work. A thread in simple terms is instruction stack that shares address space with other threads in a single process and is a unit of scheduling for OS. Most modern OS's are multithreaded so you can think of thread as a unit of scheduling for parallelism purposes and not worry about processes.

You can set number of parallel jobs using many configuration switches and GNU Parallel will run those many jobs in parallel irrespective of the number of cores. This is not ideal since it will result in overhead of thread and context switches because of scheduling more work than physical resources. In extreme cases it can result in what is called thrashing where the system spends more resources on scheduling and preparing to work and less on actually doing work. Unless the CPU is hyperthreaded, one should run one thread per cpu for optimized performance.

Relavant quote from GNU Parallel user manual:

--use-cpus-instead-of-cores Count the number of physical CPUs instead of CPU cores. When computing how many jobs to run simultaneously relative to the number of CPU cores you can ask GNU parallel to instead look at the number of physical CPUs. This will make sense for computers that have hyperthreading as two jobs running on one CPU with hyperthreading will run slower than two jobs running on two physical CPUs. Some multi-core CPUs can run faster if only one thread is running per physical CPU. Most users will not need this option.

To explore more you can easily play around by changing values of parallel and looking into system performance via top and/or w.

2
  • "one should run one thread per cpu for optimized performance" but only if the threads are CPU constrained. If you have a mix of I/O and computation, then more can be faster: If one thread is waiting for I/O another can do calculation.
    – Ole Tange
    Commented Feb 11, 2014 at 8:59
  • @OleTange and all, is there any examples that demonstrate the "differences" mentioned above? (multi-core CPUs with and without hyperthreading, single CPU-constrained and non-CPU-constrained threads, etc.) Commented Nov 19, 2022 at 8:20

Not the answer you're looking for? Browse other questions tagged .