What’s the difference between multiprocessing and multithreading?

294 views

What’s the difference between multiprocessing and multithreading?

In: 194

17 Answers

Anonymous 0 Comments

[deleted]

Anonymous 0 Comments

A thread is just a single stream of instructions that a programme intends to run. Threads run in a kind of time-share on the same processor. You can run multiple threads on a single processor. You use threads for, for example, one thread drawing the graphics while another handles the physics while another caters for the user’s inputs, etc. That way multiple things can happen at the same time and make full use of the available resources rather than having to wait one after the other. The processor gives each thread a small amount of time to do its thing, then moves on to the next thread, so each thread gets a fair share and everything “progresses” in small snippets of time.

“Multiprocessor” systems actually have entire extra full processors. This used to be called SMP. You would literally have two or more processor slots on the motherboard and two or more main processors. This is still true in servers and high-end configurations

Nowadays the line is blurring as a single physical processor can contain multiple processor cores on the same physical die (e.g. “dual core”) – so it acts like a multiprocessor system, and each of those processors is also capable of handling many threads (Intel sell this as “hyperthreading” in some instances). The same few threads that the programmers request may well be running on entirely different processors, or all on the same one.

In the grand scheme of things, you want as many processor cores as possible, and whether they are on the same processor largely doesn’t matter. Each of those processors you want handling as few threads as possible, but you also need it to be able to handle LOTS of threads – hundreds or more.

And programmers – pretty much don’t care now. They program in threads and the operating system and hardware sorts out what thread runs on what core which is on what chip, and depending on the machine, it makes the best use of the available hardware. That might mean 1000 threads all running on one processor core to save power or because you don’t have extra processors, or 1 thread running on a processor core all on its own to get the entire use of the processor for that one important thread.

But multiprocessors are like owning several apartments. Multithreading is like letting out those apartments on a timeshare. If you have 1 apartment and 50 people sharing it, each person only gets a small amount of time to do what they need to do – so it’s “slow”. If you have 12 apartments (cores) and you have 24 people (threads) sharing them, each one gets a lot more time to do what they need to do, so it’s “faster” and more people (threads) are happier than if they were all sharing the same apartment.

Anonymous 0 Comments

Imagine you’re a pizza baker
* Multithreading: You take one pizza ball, stretch it, top it and put it in the oven. While that pie bakes, you work on your second pizza and so on (you are *concurrently* working on pizzas)

* Multiprocessing: You hire 4 more people, give them all the instructions and you work on your own pizza while they work on theirs (pizzas are being prepared in *parallel*)

Anonymous 0 Comments

The other answers here are inaccurate, and missing one critical aspect — a process has its own memory segment that cannot typically be accessed by other processes. Multiple threads within a process can share the same memory. Multiprocessing needs to coordinate the communication between processes, usually with memory-mapped files or by using sockets. In some cases, like with a debugger, you can access the memory of another process but usually this is out of bounds and you can configure your system to disallow it.

Multiprocessor hardware architectures are another thing altogether. Some of the other answers are confusing that with multiprocessing which is a software topic. You can technically have multiple processes on one physical processor, and it’s multiprocessing if they are working together to do a related task.

For the baker analogy, the recipes are processes, the ovens and mixers are processors. You could have multiple threads for part of the work (e.g. mixing dry ingredients and wet ingredients at the same time before they get combined) and some work needs to be done in serial, like mixing the final batter and then putting it in the oven. This is also assuming the oven can only fit one baked good at a time, or you’d have to think of it as processor = cake sized volume in the oven, or 1 rack in the oven, or similar.

Anonymous 0 Comments

Imagine I’m playing chess with you. My brain is only concerned with this one game. This is one processor running a single thread.

Now imagine one of those grandmasters who play several games simultaneously against different opponents. That’s one processor running multiple threads: a multi-threaded scenario.

Now what of you get two people together in a team? They play against several opponents and they can each move against any of their opponents. This would be several processors working together: a multi-processor environment.

That’s it for the ELI5, but make sure to check out some of the other answers which are a bit more technical as they present interesting bits regarding the evolution of processors, cores, etc.

Anonymous 0 Comments

computers work by processing information. very fast.

Imagine you are drawing AND coloring illustrations on a book.
You can only draw/color with one pencil/brush, but you could work on more than one page, drawing all the “trees” or all the “suns, etc, without having to change from pencil to colors.

Your table (the memory) can have many different open pages, and you (the Central processing Unit/CPU) can get organized and work faster.

This is an ELI5 example of multithreading.

Add another “hand” working at your table, decide who’s drawing and who’s colouring, and that’s an ELI5 example of multiprocessing

Anonymous 0 Comments

Multithreading — Your processing is divided into multiple tasks called threads. The tasks might be worked on by a single processor taking turns doing one task and then another, or they might be worked on by any number of multiple processors.

Multiprocessing — You have more than one processor, each one capable of working on tasks.

Big programs need both to benefit. If you have a multi-processor system but haven’t divided up your work it doesn’t matter if you have 4, 8, or even 64 CPU cores to work on it because the program only has a single task thread to work on so only one of those cores will be used. On the flip side if you have a single processing CPU (rare these days) the overhead of switching between threads is a cost but there’s still only one worker to do the work. To get a good advantage you need both hardware that has multiprocessing ability and you need programs designed to work with multiple, parallel tasks.

Anonymous 0 Comments

You’re taking about two somewhat different concepts.

(1) Multiprocessor v. Uniprocessor

Recall the allied effort to break German codes in WWII? They’d have a room full of people doing a lot of math. That’s like multiprocessing — a bunch of people doing things all at the same time. They may not all be doing the same thing, but they’re all working at the same time.

The contrast is uniprocessing, where you only have ONE person doing something at once.

(2) Multithreading v. Single-threading

Threading is, basically, how many tasks are going on more/less at the same time. You can have multiple things going on either with just one person or with multiple people.

With just one person, that person does some work, gets interrupted to do something else, then switches to a third task, then returns to the first task. For example: Frieda is doing the family taxes, but when the washing machine buzzes, she stops doing the taxes temporarily and goes in to move the wash to the dryer, then returns to the taxes. Or, maybe she decides “I’m going to do my taxes for 30 minutes. Then I’ll call my friend Suzi for 30 minutes. Then I’ll go back to the taxes.”

If you have multiple people working, then you might not need to interrupt Freida. Maybe her husband Larry takes care of the wash or calls Suzi while Frieda does the taxes.

Now, technically, when you’re talking about multithreading in a computer, all of the instructions for doing those things (the taxes, talking to Suzi and swapping the wash) would live inside a single computer program. If they’re in different computer programs, then it’s usually called “multi-process” or “single-process,” but the idea is basically the same.

Anonymous 0 Comments

Using the kitchen analogy:

– Multithreading would be doing multiple recipes (or the same recipe multiple times if we are talking about the same code) on a single kitchen. If you need to share stuff between the recipes, you can just take it from the oven/counter, you just need to be careful not to pick up stuff that is unfinished

– Multiprocessing (several processes) would be akin to having several kitchens, if you need to pass ingredients/results, you’d need to use a window between them. A cook in one kitchen does not have direct access to the stuff on the other kitchen, and you probably wont pass unfinished stuff, but it also means that someone in one kitchen has to wait until something is available on the window so that it can be picked up.

– A processor is a cook, so you could technically have a single cook working on two recipes in the same kitchen (Multithreading with a single processor) in which case he needs to jump from one task to the other. You could also have multiple processes in a single processor environment, and in this case the cook needs to leave the whole kitchen and go to the other one in order to execute a different process. Now if you have two cooks in two kitchens, it’d be as two processes running on separate processors, but then there is overhead on communication between them. It all depends on how you assign work to each of the chef/kitchen combinations

Anonymous 0 Comments

Old OSs like DOS would run only one app, you would run it, work in it and close it to work with another app. Modern OSs can run multiple apps (processes) at the same time hence the name multiprocessing. This is how you can run a browser and excel together. They can’t directly communicate, unless they are designed to do so (this part is oversimplified and omits many things like debuggers and viruses), or user decides to transfer some data between them (copy paste for example)

Now, every application has a thread, in apps with a user interface it is called GUI thread. This thread receives mouse, keyboard, and all possible input from the OS, processes them, and displays results in GUI thread. What you see as applications are actually threads running.

Everything is ok, every application is running smoothly but you decided to download a file in the browser, an it froze because it has one thread and that single thread has to wait the download to finish so it can do other things like respond to cancel download button. It cannot even draw its page or menu or anything really, its single thread is busy downloading the file. Only if there was a way to download it while keeping GUI thread free. Someone said let’s create another thread in this process for other tasks, so GUI thread can work stress free. Processes can create and terminate threads as they please, but if GUI thread is terminated, app is closed. Also threads can communicate with each other since they are in the same app.

In this sense you can think processes as restaurants. A single business entity with multiple workers so each worker can work on a different aspect of the business.