multiprocessing vs multithreading vs asyncio in Python 3
PythonMultithreadingPython 3.xMultiprocessingPython AsyncioPython Problem Overview
I found that in Python 3.4 there are few different libraries for multiprocessing/threading: multiprocessing vs threading vs asyncio.
But I don't know which one to use or is the "recommended one". Do they do the same thing, or are different? If so, which one is used for what? I want to write a program that uses multicores in my computer. But I don't know which library I should learn.
Python Solutions
Solution 1 - Python
TL;DR
Making the Right Choice:
> We have walked through the most popular forms of concurrency. But the question remains - when should choose which one? It really depends on the use cases. From my experience (and reading), I tend to follow this pseudo code:
if io_bound:
if io_very_slow:
print("Use Asyncio")
else:
print("Use Threads")
else:
print("Multi Processing")
> - CPU Bound => Multi Processing > - I/O Bound, Fast I/O, Limited Number of Connections => Multi Threading > - I/O Bound, Slow I/O, Many connections => Asyncio
[NOTE]:
- If you have a long call method (e.g. a method containing a sleep time or lazy I/O), the best choice is asyncio, Twisted or Tornado approach (coroutine methods), that works with a single thread as concurrency.
- asyncio works on Python3.4 and later.
- Tornado and Twisted are ready since Python2.7
- uvloop is ultra fast
asyncio
event loop (uvloop makesasyncio
2-4x faster).
[UPDATE (2019)]:
Solution 2 - Python
They are intended for (slightly) different purposes and/or requirements. CPython (a typical, mainline Python implementation) still has the global interpreter lock so a multi-threaded application (a standard way to implement parallel processing nowadays) is suboptimal. That's why multiprocessing
may be preferred over threading
. But not every problem may be effectively split into [almost independent] pieces, so there may be a need in heavy interprocess communications. That's why multiprocessing
may not be preferred over threading
in general.
asyncio
(this technique is available not only in Python, other languages and/or frameworks also have it, e.g. Boost.ASIO) is a method to effectively handle a lot of I/O operations from many simultaneous sources w/o need of parallel code execution. So it's just a solution (a good one indeed!) for a particular task, not for parallel processing in general.
Solution 3 - Python
In multiprocessing you leverage multiple CPUs to distribute your calculations. Since each of the CPUs runs in parallel, you're effectively able to run multiple tasks simultaneously. You would want to use multiprocessing for CPU-bound tasks. An example would be trying to calculate a sum of all elements of a huge list. If your machine has 8 cores, you can "cut" the list into 8 smaller lists and calculate the sum of each of those lists separately on separate core and then just add up those numbers. You'll get a ~8x speedup by doing that.
In (multi)threading you don't need multiple CPUs. Imagine a program that sends lots of HTTP requests to the web. If you used a single-threaded program, it would stop the execution (block) at each request, wait for a response, and then continue once received a response. The problem here is that your CPU isn't really doing work while waiting for some external server to do the job; it could have actually done some useful work in the meantime! The fix is to use threads - you can create many of them, each responsible for requesting some content from the web. The nice thing about threads is that, even if they run on one CPU, the CPU from time to time "freezes" the execution of one thread and jumps to executing the other one (it's called context switching and it happens constantly at non-deterministic intervals). So if your task is I/O bound - use threading.
asyncio is essentially threading where not the CPU but you, as a programmer (or actually your application), decide where and when does the context switch happen. In Python you use an await
keyword to suspend the execution of your coroutine (defined using async
keyword).
Solution 4 - Python
This is the basic idea:
> Is it IO-BOUND ? -----------> USE asyncio
>
> IS IT CPU-HEAVY ? ---------> USE multiprocessing
>
> ELSE ? ----------------------> USE threading
So basically stick to threading unless you have IO/CPU problems.
Solution 5 - Python
Many of the answers suggest how to choose only 1 option, but why not be able to use all 3? In this answer I explain how you can use asyncio
to manage combining all 3 forms of concurrency instead as well as easily swap between them later if need be.
The short answer
Many developers that are first-timers to concurrency in Python will end up using processing.Process
and threading.Thread
. However, these are the low-level APIs which have been merged together by the high-level API provided by the concurrent.futures
module. Furthermore, spawning processes and threads has overhead, such as requiring more memory, a problem which plagued one of the examples I showed below. To an extent, concurrent.futures
manages this for you so that you cannot as easily do something like spawn a thousand processes and crash your computer by only spawning a few processes and then just re-using those processes each time one finishes.
These high-level APIs are provided through concurrent.futures.Executor
, which are then implemented by concurrent.futures.ProcessPoolExecutor
and concurrent.futures.ThreadPoolExecutor
. In most cases, you should use these over the multiprocessing.Process
and threading.Thread
, because it's easier to change from one to the other in the future when you use concurrent.futures
and you don't have to learn the detailed differences of each.
Since these share a unified interfaces, you'll also find that code using multiprocessing
or threading
will often use concurrent.futures
. asyncio
is no exception to this, and provides a way to use it via the following code:
import asyncio
from concurrent.futures import Executor
from functools import partial
from typing import Any, Callable, Optional, TypeVar
T = TypeVar("T")
async def run_in_executor(
executor: Optional[Executor],
func: Callable[..., T],
/,
*args: Any,
**kwargs: Any,
) -> T:
"""
Run `func(*args, **kwargs)` asynchronously, using an executor.
If the executor is None, use the default ThreadPoolExecutor.
"""
return await asyncio.get_running_loop().run_in_executor(
executor,
partial(func, *args, **kwargs),
)
# Example usage for running `print` in a thread.
async def main():
await run_in_executor(None, print, "O" * 100_000)
asyncio.run(main())
In fact it turns out that using threading
with asyncio
was so common that in Python 3.9 they added asyncio.to_thread(func, *args, **kwargs)
to shorten it for the default ThreadPoolExecutor
.
The long answer
Are there any disadvantages to this approach?
Yes. With asyncio
, the biggest disadvantage is that asynchronous functions aren't the same as synchronous functions. This can trip up new users of asyncio
a lot and cause a lot of rework to be done if you didn't start programming with asyncio
in mind from the beginning.
Another disadvantage is that users of your code will also become forced to use asyncio
. All of this necessary rework will often leave first-time asyncio
users with a really sour taste in their mouth.
Are there any non-performance advantages to this?
Yes. Similar to how using concurrent.futures
is advantageous over threading.Thread
and multiprocessing.Process
for its unified interface, this approach can be considered a further abstraction from an Executor
to an asynchronous function. You can start off using asyncio
, and if later you find a part of it you need threading
or multiprocessing
, you can use asyncio.to_thread
or run_in_executor
. Likewise, you may later discover that an asynchronous version of what you're trying to run with threading already exists, so you can easily step back from using threading
and switch to asyncio
instead.
Are there any performance advantages to this?
Yes... and no. Ultimately it depends on the task. In some cases, it may not help (though it likely does not hurt), while in other cases it may help a lot. The rest of this answer provides some explanations as to why using asyncio
to run an Executor
may be advantageous.
- Combining multiple executors and other asynchronous code
asyncio
essentially provides significantly more control over concurrency at the cost of you need to take control of the concurrency more. If you want to simultaneously run some code using a ThreadPoolExecutor
along side some other code using a ProcessPoolExecutor
, it is not so easy managing this using synchronous code, but it is very easy with asyncio
.
import asyncio
from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor
async def with_processing():
with ProcessPoolExecutor() as executor:
tasks = [...]
for task in asyncio.as_completed(tasks):
result = await task
...
async def with_threading():
with ThreadPoolExecutor() as executor:
tasks = [...]
for task in asyncio.as_completed(tasks):
result = await task
...
async def main():
await asyncio.gather(with_processing(), with_threading())
asyncio.run(main())
How does this work? Essentially asyncio
asks the executors to run their functions. Then, while an executor is running, asyncio
will go run other code. For example, the ProcessPoolExecutor
starts a bunch of processes, and then while waiting for those processes to finish, the ThreadPoolExecutor
starts a bunch of threads. asyncio
will then check in on these executors and collect their results when they are done. Furthermore, if you have other code using asyncio
, you can run them while waiting for the processes and threads to finish.
- Narrowing in on what sections of code needs executors
It is not common that you will have many executors in your code, but what is a common problem that I have seen when people use threads/processes is that they will shove the entirety of their code into a thread/process, expecting it to work. For example, I once saw the following code (approximately):
from concurrent.futures import ThreadPoolExecutor
import requests
def get_data(url):
return requests.get(url).json()["data"]
urls = [...]
with ThreadPoolExecutor() as executor:
for data in executor.map(get_data, urls):
print(data)
The funny thing about this piece of code is that it was slower with concurrency than without. Why? Because the resulting json
was large, and having many threads consume a huge amount of memory was disastrous. Luckily the solution was simple:
from concurrent.futures import ThreadPoolExecutor
import requests
urls = [...]
with ThreadPoolExecutor() as executor:
for response in executor.map(requests.get, urls):
print(response.json()["data"])
Now only one json
is unloaded into memory at a time, and everything is fine.
The lesson here?
> You shouldn't try to just slap all of your code into threads/processes, you should instead focus in on what part of the code actually needs concurrency.
But what if get_data
was not a function as simple as this case? What if we had to apply the executor somewhere deep in the middle of the function? This is where asyncio
comes in:
import asyncio
import requests
async def get_data(url):
# A lot of code.
...
# The specific part that needs threading.
response = await asyncio.to_thread(requests.get, url, some_other_params)
# A lot of code.
...
return data
urls = [...]
async def main():
tasks = [get_data(url) for url in urls]
for task in asyncio.as_completed(tasks):
data = await task
print(data)
asyncio.run(main())
Attempting the same with concurrent.futures
is by no means pretty. You could use things such as callbacks, queues, etc., but it would be significantly harder to manage than basic asyncio
code.
Solution 6 - Python
Already a lot of good answers. Can't elaborate more on the when to use each one. This is more an interesting combination of two. Multiprocessing + asyncio: https://pypi.org/project/aiomultiprocess/.
The use case for which it was designed was highio, but still utilizing as many of the cores available. Facebook used this library to write some kind of python based File server. Asyncio allowing for IO bound traffic, but multiprocessing allowing multiple event loops and threads on multiple cores.
Ex code from the repo:
import asyncio
from aiohttp import request
from aiomultiprocess import Pool
async def get(url):
async with request("GET", url) as response:
return await response.text("utf-8")
async def main():
urls = ["https://jreese.sh", ...]
async with Pool() as pool:
async for result in pool.map(get, urls):
... # process result
if __name__ == '__main__':
# Python 3.7
asyncio.run(main())
# Python 3.6
# loop = asyncio.get_event_loop()
# loop.run_until_complete(main())
Just and addition here, would not working in say jupyter notebook very well, as the notebook already has a asyncio loop running. Just a little note for you to not pull your hair out.