Concurrency vs Parallelism Part2

Parallel and Concurrent are related ideas, but concurrent program is really what we're going to do and they're slightly different.‎

Concurrent execution is not necessarily executing at the same time. It could be, but it's not necessarily.‎

But you say two tasks are concurrent if the start time and the end time of the tasks overlap. So, that range of time between start and end for these two tasks, if they overlap, then you say that is concurrent. That does not mean that they're literally executing at the same time, where with parallel, they have to literally be executing at the same time.

So, one might ask why do concurrent execution if you're not executing at the same time, if it's not actually parallel? Maybe concurrent execution is not beneficial, right? 

Okay so, just again to reinforce this difference between concurrent and parallel, parallel tasks must be executed on different hardware. In order to execute in parallel, you need different hardware, different cores typically.‎

Concurrent tasks may be executed on the same hardware but may not, you can execute them on one piece of hardware, one core, and you can still say this is concurrent execution but only one task executed at a time.‎

The process of mapping the task to hardware is not directly controlled by the programmer. So, when I say mapping the task to the hardware, you've got these tasks, task one, task two, that you need to perform on some hardware, core one core two. And determining which core is performing which task, that's what I'm calling a hardware mapping. ‎

That is not directly controlled by the programmer. Now there exist languages where the programmer directly controls that sort of thing.‎

So, most of the time, in a programming language, when you program, when you do concurrent programming, the programmer in doing their concurrent programming, they're determining which tasks can be executed in parallel. ‎

Also, there terming a few other things like what kind of communication there is between the tasks, maybe one sends data to the other, are also synchronization events.‎

A programmer describes what can be executed in parallel, not how will be executed in parallel.

What will be executed in parallel depends on how the tasks are mapped to hardware.

Now, how the tasks are mapped to hardware, that is not directly in the control of the programmer, that's left to the operating system.

Why Concurrent Programming?‎

Now, let's say you are doing this, say you have one core. So you're doing concurrent programming but you've only got one core, so you can't actually get parallelism.

So, one might say, look, why? Why go to all that effort of concurrent programming?

If I'm only going to get concurrency anyway everything's happening one instruction at a time, these tasks can't actually run together at the same time.

 

So, even though you can't get parallelism, maybe can't get parallelism cause you don't have concurrent multiple processes, multiple cores, but you can still get significant performance improvement just from using concurrency.

So, the reason why this happens is because typically, tasks have to periodically wait for some event, some slow event.‎

Now, there are many of these slow events, typical input-output things. So the idea is that in a machine there's a CPU, a processor, and that runs fast.

When the processor has to communicate with other things that are other chips on the same board, that is slow.

So for instance say I got my processor and it needs to talk to some memory that is far away on the board.

So he's got to communicate with a memory to grab some data from memory. And memories are slow so you typically have to wait for that.

Maybe it wants to send data on the network, so it's got to communicate with this Ethernet card, or Wi-Fi card. And the Wi-Fi card is slow, it takes a certain amount of time to hand over the communication to receive or send.

So anytime the CPU wants to do- or maybe you want to put something on screen, you've got to go to a video card. So the CPU is communicating with a video card and that has a certain delay.

So when you have these IO activities where the CPU is communicating with something else on the board but separate from it, those are slow and often the code has to wait until those things are done.

When these events happen, you would rather not have your processor just waiting for memory. or interet communication , etc …

So if you have multiple tasks that all can execute when task 1 is waiting for memory, task 2 can execute, and then when task 2 maybe it hits a memory access, then task 3 can execute while the other guys are waiting. So that's called hiding latency.

That's generally what you refer to with hiding latency. So there's a latency, like a wait time latency.

So say I'm going to memory I need to wait 100 cycles. You can hide that latency by just taking another task that's ready to run and execute that while you're waiting on the first event.

So even without having parallel hardware, just writing concurrent code can give you this significant advantage in performance because your program no longer has to wait on IO input-output accesses, whatever type of input-output accesses. No longer has to wait it can just run and our program's ready.

And so things can still get done faster. So concurrent programming is useful even without parallel hardware.

One good thing about traditional programming languages is that when you're writing code in these languages you are not directly aware of the underlying hardware architecture. You don't know is an I7 or is this an I3 or whatever.

You don't know that, and you don't care. And you don't know exactly what the architecture looks like and you don't generally care.

So in any Programming language, when doing concurrent programming, we can define which task can be performed in parallel, but which and how tasks are performed in parallel is left up to the operating system, The programmer doesn't have to consider that.

-Parallel Execution

-Concurrent Execution