# Pipeline and real parallelism?

I have read several articles which say that the CPU has the ALU (and other small specific execution units), Control Unit and the Registers and well other buffers/pipelines, internal buses etc.

The Control unit:

The control unit implements the architecture of the CPU. It performs the tasks of fetching, decoding, managing execution and then storing results.

Studying pipeline concept, and what I understand is that at least two steps:

1. Fetch,Decode--->CONTROL UNIT

2. Execute-------->ALU and OTHER EXECUTE UNITS


Both steps PERFORMED IN PARALLEL. That is, while the CPU is executing an instruction, at that same time another is being fetched and decoded.

Am I correct in assuming the above? Or do the Control unit and Execution unit work one after the other like some kind of switching between clock cycles?

• Think of it like an assembly line - each stage does its part and passes the results along to the next, so at the start of every clock cycle, each stage is working in parallel, i.e., at the same time. Note however, the different stages may take different amounts of time to complete their tasks, and the pipeline can only be clocked as fast as the slowest stage will allow. Therefore, by the end of a cycle, most stages will be idle. The ideal is to 'balance' the pipeline so each stage works in the same amount of time. Oct 18 '12 at 3:14

Yes. This is the exactly benefit in use a pipeline. The most simple real life example is a laundry.

When you just arrive there, you have dirty clothes that you want to "process". You put the first group of clothes inside the washer and wait until it finishes. When it is ready, you get your first pack of clothes and put all in the dryer machine and fetch and load more clothes into the washer in parallel. When the dryer end its job you then start the "folding cycle", releasing the dryer.

I think you get the idea that while you are folding you can load more clothes in the washer and dry more clothes from the washer in parallel.

The main idea in both cases, processor and laundry, are similar: you can do more in less time by doing parallel jobs.

In the opposite, a processor without a pipeline have to wait all the execution ends to fetch another instruction. Using the laundry analogy again, it is like you only start to wash another group of clothes only after fold all clothes from the first group, wasting time in the middle.

• An essential feature of pipelining, which is distinct from more "general" parallelism, is that it improves throughput without requiring additional "processing" capability. Someone with one washer, one dryer, and one folding table, who is able to use all at once, may achieve better throughput than someone who has two washers, two dryers, and two folding tables, but who can only use one kind of thing at a time, despite the fact that the latter person would have more equipment. Oct 16 '12 at 21:36
• Very good comment, gives a clear understanding of the answer. thanks Oct 17 '12 at 15:41

Yes, in a hardware pipeline, all of the steps are happening in parallel.

• really parallel, not assumed parallel,okay but wait what do you mean by "hardware pipeline"? there is a SOFTWARE PIPELINE? also??? Oct 16 '12 at 20:57
• Well, sure. You didn't specify in your question, so I just wanted to make sure my answer was precise. Oct 16 '12 at 21:12
• so if there is only software pipelining but there is no support from the hardware then it would be assumed parrallelism so in the case of SOFTWARE ONLY PIPELINE do we still get the performance increase in throughput and response time? Oct 17 '12 at 15:44

http://en.wikipedia.org/w/index.php?title=File:Intel_Core2_arch.svg&page=1

Actually there are both series & parallel operations in a pipe to maintain cache concurrency and pre-fetch and pre-decode instructions on a 128 bit bus. The depth of each level of bus including 2 levels of cache, as it gets deeper, adds to latency, but also improved access time when frequently accessed from cache (called cache hits). When an object is locked to an I/O and another thread wants to access the same object, resource management either blocks permissions to write requests or locks the object until free. Cache size increases permit this frequent occurrence to be delayed less for parallel operations by adding serial delay or re-ordering requests, when it is not shareable. If you watch windows code execute using procmon.exe, many poorly written programs will experience fast i/o failure followed by normal I/O success. (not just windows)

Parallel cores must be managed with segregated threads to avoid concurrent lock-outs.

• what did you just say, i guess your explanation is toooo high level... Oct 16 '12 at 20:55