CODEWITHSUNDEEP
multithreadingfork
Yves
Yves

Reputation: 12431

fork vs thread on one single core

Imagine that I have two tasks, each of them needs 2 seconds to finish its job.

In this case, if I create two threads for each of them and my PC is single-core, this won't save any time. Am I right ?

What if I use fork to create two processes (the machine is still single-core) and each process takes charge of one task ? Can this save any time ?

If not, I have a question:

In current modern machine (including multi-core), if I have several heavy tasks, which method should I use ?

Upvotes: 0

Views: 1951

Answers (2)

Serg M Ten
Serg M Ten

Reputation: 5606

Even with a single core having two threads may speed up execution. If your routine is purely CPU bound then two threads won't improve anything, indeed the performance will be worse because of context switching overhead. But if the routine has to wait for memory, disk or or network (which is usually the case) then two threads will provide performance gains even with a single core.

About fork vs threads, threads require less resources so, in principle, should be the first choice. But there are two caveats: 1) maybe you want to be able to terminate a parallel routine, this is much safer to do with processes than with threads and 2) some languages (notably Python and Ruby) provide pseudo-thread libraries which do not use real threads but switch between routines using the same thread. This simulated threading can be very useful for example when waiting for network requests but it must be taken into account that it's not real multithreading.

Amendment: As commented by Sergio Tulentsev, Ruby and Python do indeed provide real threads and not only coroutines.

Upvotes: 1

tofro
tofro

Reputation: 6073

"job takes 2 seconds" - If those 2 seconds are fully occupying the CPU (100% load), you won't gain anything with either thread nor fork if you have no cores to share. The single-core CPU is simply busy and you cannnot make it more busy.

In case this 2 seconds include waiting time (for example on I/O, storage, whatever) you could gain something, even with a single core. The amount of gain depends on the CPU working vs. CPU waiting ratio and the overhead of your multiprocessing. Most non-trivial programs have at least some amount of "CPU waiting", so multithreading is often useful even on single-core CPUs.

This overhead for setting up a coroutine and context switching can be considerable and needs to be measured. Obviously, the shorter the run time of your actiual task is, the larger will be the ratio of overhead (for setting up a thread or process, etc.) and the smaller will be you multi-processing gain.

Traditionally, threads used to have considerably less overhead than processes (after all, that was why they were invented), but the "considerably" has maybe vanished over time - On modern Linux systems, processes are only a tad slower to set up than threads (actually, both use the same system calls). You rather decide between thread or process based on the requirements related to amount of protection (or sharing) of data than execution speed.

Upvotes: 0

Related Questions