concurrent.futures vs multiprocessing
In this lesson, you’ll see why you might want to use
concurrent.futures rather than
multiprocessing. One point to consider is that
concurrent.futures provides a couple different implementations that allow you to easily change how your computations are happening in parallel.
In the next lesson, you’ll see which situations might be better suited to using either
multiprocessing. You’ll also learn about how that ties in with the Global Interpreter Lock (GIL).
So, that was pretty easy to do. You may be wondering, “Okay, why should I use this thing here over
multiprocessing, or over a
multiprocessing.Pool?” Well, what’s kind of nice is that the
concurrent.futures module, it provides a couple of different implementations that allow you to change very easily how your computations are happening in parallel.
Now you can see here that the
ThreadPoolExecutor actually performed all of these calculations within a single process spread out across multiple threads. In this case, it’s even faster, but this is just a toy example. It’s not really doing anything, it’s just sleeping for a second.
00:50 But you can already see here that the big difference is that now, everything is running within a single process. Parallel computation is happening because we have multiple threads within that single process that are working on this data in parallel.
Become a Member to join the conversation.