Note the number of "simultaneous" instruction streams and the number of "concurrent" instruction streams. Relates to the discussion on "parallel" and "concurrent" execution in the first lecture.
TA-lixf
@rohit, good note.
Could someone else please explain the distinction between "simultaneous" instruction streams and "concurrent" instruction streams?
Azerty
Wouldn't concurrent instruction streams be some sort of simultaneous instruction streams, but where there would dependency or interactions between the different streams?
rbcarlso
@TA-lixf: Here's concurrency vs. simultaneity as I understand it:
Two instruction streams are simultaneous if the instructions are being read by different cores (that is, different fetch/decoders or orange boxes), so they are literally being executed at the same time. They are running in parallel.
Two instruction streams are concurrent but not simultaneous if they are running on the same core. That is, same orange box, but different register contexts or blue boxes. Only one of them will have its instructions executed at a time, but the hardware may decide to switch between them at any time, so to avoid race conditions the instruction streams must be written so that neither has to finish before the other. They are not running in parallel, but they should act as if they are.
The advantage of having four concurrent instruction streams on 1 core (x16 cores = 64 concurrent instruction streams) is that the hardware can switch between instruction streams without swapping in a new context, so it can make the switch in one cycle. If there are more than four threads assigned to a single core in this example, the OS may have to reload a blue box with information in a cache, which is good enough to hide latency for data coming in from main RAM but is still much slower.
Someone please correct me if any of this is inaccurate.
kayvonf
There is also a good discussion about concurrent vs. simultaneous based on the first slide in the course.
Note the number of "simultaneous" instruction streams and the number of "concurrent" instruction streams. Relates to the discussion on "parallel" and "concurrent" execution in the first lecture.
@rohit, good note.
Could someone else please explain the distinction between "simultaneous" instruction streams and "concurrent" instruction streams?
Wouldn't concurrent instruction streams be some sort of simultaneous instruction streams, but where there would dependency or interactions between the different streams?
@TA-lixf: Here's concurrency vs. simultaneity as I understand it:
Two instruction streams are simultaneous if the instructions are being read by different cores (that is, different fetch/decoders or orange boxes), so they are literally being executed at the same time. They are running in parallel.
Two instruction streams are concurrent but not simultaneous if they are running on the same core. That is, same orange box, but different register contexts or blue boxes. Only one of them will have its instructions executed at a time, but the hardware may decide to switch between them at any time, so to avoid race conditions the instruction streams must be written so that neither has to finish before the other. They are not running in parallel, but they should act as if they are.
The advantage of having four concurrent instruction streams on 1 core (x16 cores = 64 concurrent instruction streams) is that the hardware can switch between instruction streams without swapping in a new context, so it can make the switch in one cycle. If there are more than four threads assigned to a single core in this example, the OS may have to reload a blue box with information in a cache, which is good enough to hide latency for data coming in from main RAM but is still much slower.
Someone please correct me if any of this is inaccurate.
There is also a good discussion about concurrent vs. simultaneous based on the first slide in the course.