Concurrency vs parallelism

2021년 7월 1일About 3 min

Concurrency vs parallelism 관련

Swift Concurrency by Example

Back to Home

Concurrency vs parallelism | Swift Concurrency by Example

Concurrency vs parallelism

Updated for Xcode 15

When working through concurrency in Swift, there are two words we use a lot: concurrency and parallelism. We give them very specific meanings that might not quite match how you use them in English, so it’s worth clarifying up front what they mean in this specific context.

Imagine a single-core CPU running a desktop operating system: the user can run lots of programs, use the internet, maybe play some music, and from the user’s perspective all those things are happening at the same time. However, we know that isn’t possible: they have a single-core CPU, which means it can literally only do one thing at a time.

What you’re seeing here is called concurrency: our user’s apps have been written in such a way that one CPU core can juggle them so they appear to be running at the same time. One starts, makes a tiny bit of progress on its work, then pauses so that another one can start, make a bit of progress on its work, then pause, and so on. Because the CPU flips between programs so quickly, they appear to be running all at the same time, when really they aren’t.

As soon as you add a second CPU core to a computer, then things can run in parallel. This is when two or more programs run at the same instant: one on the first core, and another on the second. As you might imagine, this means work can happen up to twice as fast because two programs are able to run at the same time.

The really interesting stuff lies in our ability to split up work in a single program. Yes, having two CPU cores allows a computer to run two separate programs at the same time, but we can also split up our work into smaller parts called threads, and those can be run in parallel too.

This splitting up of functionality requires us to do work – Swift can’t decide by itself to run some parts of our code in parallel with other parts, because that would introduce a lot of surprising bugs. Instead, we have to tell Swift ahead of time which parts of our code can be split up if needed, and also tell it what we should do when those tasks complete.

When you boil it right down, that’s the topic of this whole book: teaching Swift how it can split up the work in our programs so it runs as efficiently as possible. And it is about efficiency, because some Apple devices have many CPU cores – if your app is running full screen on that device and you’re only ever using one of those cores, you’re only getting a tiny fraction of the device’s possible performance.

More importantly, you’re also helping to make sure your app remains responsive the entire time. Imagine if your user interface froze up every time you were waiting for the response to a network request – it would be a pretty horrible experience, right?

There’s a famous computer scientist called Rob Pike, and I think he explained the difference between concurrency and parallelism beautifully. Here’s what he said:

“Concurrency is about dealing with many things at once, parallelism is about doing many things at once. Concurrency is a way to structure things so you can maybe use parallelism to do a better job.”