Multiprocessing vs multithreading

Question

During my last job interview which was about half year ago, the technical guy asked me, whether the better option is to use e.g. 100 processes to do some work, or only one process but with 100 threads.

There wasn't any information about how many cores the CPU has.

I'm aware that the best answer is...it depends but..

In my opinion the 100 threads solution is (in general) better because:

• threads shares the same memory

• there is no necessity to inter process communication

• creating new thread is cheaper (in resources) than creating process

• between threads there is possibility to use just pointers

Unfortunately I didn't get any feedback that the answer I gave was right or not.

Ultimately I didn't accept the offer of that company, because...well I got a really better one, but I would like to know, what is the "best" answer of that question.

Answer 1

The question is somewhat disconnected from reality but it highlights some interesting engineering topics.

First things first: define the requirements

“Better” must be better defined: is it better robustness or better performance ?

Better robustness ?

The answer should be 100 processes: if any of the process would fail, the others would continue to work.

If you’d go for the threads, a bug on a single thread could corrupt the memory and cause the whole system to fail.

Better performance ?

It depends on the processing capacity, and more precisely the number of CPUs and cores:

In most of the cases the 100 threads will outperform 100 processes, if there are not enough processors.

Why? Because the threads as well as the processes would have to do context switches to share the processor:

• for threads this is very light, since only registers and some key data/execution structures need to be switched.
• in comparison, the context switch for processes is much more comprehensive, since you’d also need to ensure memory address space segregation (virtual memory address space swap) , and OS resources (e.g. open files, etc...). So the performance overhead is higher.

Of course, if you have enough processors to compensate this overhead, the 1000 processes could be a choice... unless
they are not completely independent, and need to communicate, which could create a bottleneck in the system, for example due to IPC.

Answer 2

In my opinion the 100 threads solution is (in general) worse because:

• threads shares the same memory, which means one misbehaving thread can corrupt another thread's memory

• there is no well-defined inter process communication, threads simply write into each other's memory.

• creating a new thread is as cheap as creating a new process in well-designed systems (e.g. on the BEAM/HiPE VM, a process uses just ~300 bytes of memory, and it is trivially possible to have 1 million processes even on a not very beefy laptop)

• between threads there is possibility to use just pointers, meaning that threads can read and write other thread's memory without any form of checking or protection

Answer 3

Without any context it is indeed impossible to point out a winner. There are more things to consider than just the technical, performance related questions. Like

• Location (can the tasks run on the same machine?)
• Are the tasks depending on each other in terms of execution order or data needs?
• The responsibilities for the tasks at hand (who is to do or authorize them?)
• Security issues (accessibility to input and output).

These can all impact your choice. A process is something different than a thread from an organizational point of view. A thread is an execution path within a process so they do not compare well. It is like asking which are better, desktop applications or web applications?

Let's not be too smart over this and focus on performance issues for a moment. Now we still have some questions to answer.

Those 100 execution paths, are they going to be equally busy? It is not uncommon to have a lot of threads in a single process but typically most would be asleep. It is not effective to have them all compete for CPU cycles at the same time so if you have this many threads you want to make sure that no more than some (depending on the number of cores you have to spare) will run at the same time. There are ways to do that. If tasks are basically independent from one another and you just want to do the work as quickly as possible, using threads this way is hard to beat... for a single machine scenario. Because this does not scale well.

Processes can be distributed over an unlimited number of machines, which scales a lot better when just looking at the number of execution paths you could possibly follow simultaneously. But then the question would be where the data is coming from and if there is an issue with distributing input data for those threads. It is impossible to say what the bottleneck is going to be without further context.

So it may have been a smart question with the sole purpose of seeing how strong you are when it comes to getting the information you need to do a good job. You get an unworkable request, what do you do? Will you jump to conclusions and bang away based on assumptions (or without a clue), or will you be a pain in the ass and keep asking until you understand exactly what your client needs? This would tell them something about your understanding of computer science and about whether your personality is up to the challenges typical to their environment.