Understanding Pipelining and Superscalar Execution

P&H - Pipelining by minesweeper · 2002-12-19 13:24 · Score: 5, Interesting

from the read-hennessy-and-patterson-first dept.

I just finished a CS course co-taught by Professor Patterson, and our primary text this semester was Patterson and Hennessy's Computer Organization and Design.

When we discussed pipelining this semester, the analogy used was the four stages of doing laundry: washing, drying, folding, and stashing. Here are the lecture notes (both PDF). The notes spend a good deal of time going over the hazards of pipelines and how to avoid them.

Re:P&H - Pipelining by AvantLegion · 2002-12-19 13:34 · Score: 3, Funny

Although, I wonder what Ann/Brian/Cathy/Dave do in that laundry room to fill delay slots when nobody's looking.....
Re:P&H - Pipelining by (startx) · 2002-12-19 13:44 · Score: 2

aahhhh!! It's that damn book! I've had nightmares about that book! They used it here to teach MIPS asm, and then the next semester it's used to teach "bum bum bum!" cpu organisation (sp) and design.
Re:P&H - Pipelining by Jucius+Maximus · 2002-12-19 13:56 · Score: 5, Interesting

"I just finished a CS course [berkeley.edu] co-taught by Professor Patterson, and our primary text this semester was Patterson and Hennessy's Computer Organization and Design [berkeley.edu]. When we discussed pipelining this semester, the analogy used was the four stages of doing laundry: washing, drying, folding, and stashing. Here are the lecture [berkeley.edu] notes [berkeley.edu] (both PDF). The notes spend a good deal of time going over the hazards of pipelines and how to avoid them."
I just finished an engineering course with the exact same book, and we did that exact same pipelining example. I must say that the books is really very good at explaining the workings of the CPU.
The best teacher, though, is design. As part of the course, we all formed groups and actually designed and implemeted basic non-pipelined CPUs in VHDL and, if they fit, we implemented them on FPGA (field programmable gate array) boards. And by 'simple' CPUs, I mean that the CPUs have like 4K RAM, maybe 8 registers, ran at ~3 cycles per instruction, and only have about 12 instructions total. But it was REALLY informative because it forced us to learn the exact purpose of everything in the CPU.
Re:P&H - Pipelining by geekee · 2002-12-19 14:18 · Score: 2

Didn't Patterson invent the SPARC risc architecture? I believe Hennessy invented MIPS. A very good book. Hennessy is president of Stanford now too.

--
Vote for Pedro
Re:P&H - Pipelining by j3110 · 2002-12-19 14:20 · Score: 2

Now everyone will know why the P4 sucks :) Honestly, in order to double the pipelines length, you really need to be twice as accurate with branch prediction, or else it will be slower per clock speed. It does make it easier for a chip to go faster, to a certain point, but the P4 is a bit excessive :) I just wonder sometimes if the Intel designers have ADD (think rambus (bad idea... memory width is a good thing!), P4 (don't increase the pipeline's length unless you have a good reason), Itanitium (scrap an entire architechture for one that allows you to disable instructions, so that it is gauranteed that part of the processor won't be used at that point)).

--
Karma Clown
Re:P&H - Pipelining by Wesley+Felter · 2002-12-19 14:29 · Score: 3, Insightful

Performance per clock doesn't really matter, because lengthening the pipeline allows higher frequencies. I think a better metric is maximum performance in the same process, and the Pentium 4 wins there (unless you care about cost; then it gets tricky...).
Re:P&H - Pipelining by The+Salamander · 2002-12-19 14:54 · Score: 2, Funny

Spawn some children? Oh sorry, that's the OS class.
Re:P&H - Pipelining by cheezedawg · 2002-12-19 17:14 · Score: 4, Informative

to a certain point, but the P4 is a bit excessive

Actually, there is a lot of research about pipeline depths, and here is a paper that calculates the optimal pipeline for x86 to be around 50 stages. In fact, they theorize that you could see up to a 90% increase in performance in the P4 by making the pipeline even deeper. So not everybody thinks that the P4 pipeline is "a bit excessive."

think rambus (bad idea... memory width is a good thing!)

I'm a little confused here- until the past few months, Rambus still offered superior memory bandwidth. It wasn't until DDR333 and higher that SDRAM started to catch up. Rambus didn't lose in the market because of performance.

Itanitium (scrap an entire architechture for one that allows you to disable instructions, so that it is gauranteed that part of the processor won't be used at that point)

That is a pretty strange complaint about Itanium. In fact, I think that it is weird that you even think that is a problem.

--
"The defense of freedom requires the advance of freedom" - George W Bush
Re:P&H - Pipelining by j3110 · 2002-12-19 18:22 · Score: 3, Informative

A 50 stage pipeline wouldn't be bad if it were done differently. I still prefer the old "have one instruction after the branch that always is executed" method. Only with a longer pipeline, you would need more instructions. A good optimized compiler could handle this MUCH better than a processor could. Longer pipelines need better branch prediction. I don't really care about your research, because it's all theory. It's pretty appearant from comparing P3 to P4 that longer pipelines are only better if you can manage to crank out a factor of speed greater than the factor of increase in pipeline length. The whole "Software isn't compiled for P4 optimizations" arguement is really dumb when you think about it. If it can't run X86 faster, then it must really suck. In order to compensate for this, they have to run the P4 at much faster clock rates, and the compiled binaries have to be larger so as to place the jump points in strategic positions. Deeper pipelining will cause you to run into problems of silicon transistor switching speed much earlier than you would usually as well.

Rambus is a bad idea. It had very much inferior latency that increased with each memory module you add. The processor waits everytime you ask for ram. That's wasted cycles. There is a reason the P4 has an internal bus that is VERY wide compared to other processors. DDR's memory speed is in no way related to the bus's inferiority. The faster you make the chips, the faster the processor gets the data. With RAMBUS, you have additional latencies for the same speed of RAM. They are all made from the same DRAM design, and with the same speed chips, a wider bus will be faster.

I'm not upset that the Itanium changes instructions sets. I just don't think that any processor that disables part of itself will ever be optimal. I don't think lugging around old instruction sets are a good idea either. It's a waste of space that could have been used for some more full multipliers.

Don't take my word for it... go clock a P4 against another CPU and see how well it performs in sorting with RAMBUS memory. The bulk of the P4's gains on any other CPU comes from SSE2, 400Mhz FSB, and CPU clock speed. Take those away, and it will be slower per clock cycle than any other CPU (including P3), especially if it has RAMBUS memory.

--
Karma Clown
Re:P&H - Pipelining by cheezedawg · 2002-12-19 21:01 · Score: 2

I think you are missing the point- you increase the pipeline depth so you can increase the clock speeds. Of course it will do less per cycle- that's the definition of a pipeline. But it gives you a much more scaleable design and the end result is better performance. The paper says that given the current timings and branch prediction accuracies, you can increase the performance a lot by playing with the pipeline depth and cache sizes.

It's pretty appearant from comparing P3 to P4 that longer pipelines are only better if you can manage to crank out a factor of speed greater than the factor of increase in pipeline length.

Look at the clock speeds of the P3 (architecture maxed out around 1.5 GHz) and P4 (3 GHz with lots of room to grow). They have "cranked up the speed" by more than enough to compensate for the lower IPC. If you are comparing a 1.5 GHz P3 to a 1.5 GHz P4 then you have missed the whole point entirely.

Longer pipelines need better branch prediction.

Branch prediction is already very good. Are you suggesting that you should slow down the rest of the chip so the less than 5% branches that are mispredicted won't be as expensive? That's a pretty dumb trade-off.

Don't take my word for it... go clock a P4 against another CPU and see how well it performs in sorting with RAMBUS memory

Ok- how about this:

Still, the actual Rambus technology leaves no room for complaint: RDRAM offers a large bandwidth of up to 4.2 GB/s and offers the best performance, particularly when used together with the Intel Pentium 4. ...
Here, you should keep in mind that the Intel Pentium 4 has a maximum bandwidth of 4.2 GB/s. In the near future, this will reach well over the 3 GHz limit. Only Rambus memory in the form of PC4200 (533 MHz) is capable of taking full advantage of this bandwidth. By using DDR SDRAM, such as DDR266 or DDR333, the bandwidth remains restricted to 2.1 GB/s and 2.7 GB/s, respectively.
With higher latencies and all (which are becoming less significant), the P4 has always and still does perform the best with Rambus.

The bulk of the P4's gains on any other CPU comes from SSE2, 400Mhz FSB, and CPU clock speed. Take those away, and it will be slower per clock cycle than any other CPU (including P3)

Once again, nobody disputes that the P4 is "slower" per clock cycle than other CPUs. That is why it is clocked 1 GHz higher than its competition, and it still has room to grow (current Athlon designs can't go much faster). Your statement is analogous to saying "Take away these extra french fries and larger drink from my super-sized value meal, and its just the same as a regular value meal".

--
"The defense of freedom requires the advance of freedom" - George W Bush
Re:P&H - Pipelining by iabervon · 2002-12-20 04:54 · Score: 2

That seems to be a common analogy for pipelining, and is actually quite useful, since it extends to cases where you have two washers and a big dryer, or one washer and two slow dryers, or you're in a dorm and have a dozen of each, but you have to run the dryers several times each to get stuff dry (and then you go to work at Intel).

Am I the only person who therefore uses the word "clock" for what you do when a step has finished?
Re:P&H - Pipelining by j3110 · 2002-12-20 07:01 · Score: 2

Ok, If you don't say that the Pipeline allowed them to get 2x the clock speed (the fastest Athlon is 2.17 Ghz ATM), then I won't say that it hasn't let them crank out an extra 38% cycle speed.

If they catch branches early on (by the 5th stage), then they will not loose much performance. But because there are 10 instructions still not complete, it's unlikely they could catch the branch until all the instructions are complete and ready to write back to ram. Consider also the super scalar nature of the CPU. Now we are sitting around the 13th stage of the pipeline and we know which way to branch. If we were wrong, we loose 12*2=24 clock cycles. If branch prediction is 90% accurate(a stretch I would say) and code is about 10% branch statements, then 1 in every 100 instructions will cause you to loose 24 clock cycles. That's only branching! Now lets take that 20% of the time, the next instruction references the result of the current instruction. That usually causes the processor to insert NOPs into the pipe just after the decode until there is enough spacing between them so that the data can be forwarded to this instruction when it is ready for it's operands. In a normal pipe, that's only about 2 clock cycles. In a P4 pipe, that has to at least be 6. This is a factor or 3 slower about 20% of the time. That's about the same for branches. A good 1/3 of the cpu time is 3x slower on a P4. Sure you can compile around some of it, but that is just silly. That's why P4 introduced hyper threading that nothing is using. So instead of inserting NOPs, it can insert instructions from other programs that can't possibly reference the same data. That would be great, but it can be applied to shorter pipes just as well.

The majority of the performance increase of P4 has nothing to do with the pipeline. If the P4 was built on a normal pipeline, you could have expected to see a 2.2 Ghz machine right now that blew the AMD away.

Intel had a good chance with their Itanium to make a good RISC processor. A good load-store, 4/8 way super scalar, with a short pipeline, and it could still do 3Ghz easy. Instead, they decided to graft on the kitchen sink and a million other transistors that will lie dormant half the time. Most of the CPU will be sleeping even when you need it. I'm more excited about the new IBM processors for the mac.

--
Karma Clown

Branch Prediction by hng_rval · 2002-12-19 13:27 · Score: 5, Informative

One thing that his excellent analogy leaves out is the concept of branch prediction.

For those of you who didn't major in CS...

Imagine that we finish the first stage of building our SUV (building the engine) and commence with stage 2 (putting the engine in the stasis). While we are doing that we are building another engine for SUV #2. However, what if the next customer didn't want an SUV, but instead wanted a compact car. We have to throw away our engine for SUV #2 and start over. We wasted an entire stage!!

This analogy doesn't work so well it seems. So we'll stick with computers. If you have 5 instructions in your pipeline and one of them is a conditional branch (think, If the user hit ENTER, print a message to the screen. If they hit escape, BSOD).

If the conditional instruction is high up in the pipeline then every instruction under it could be wasted. Obviously, if the processor could predict which path the branch would follow it would waste less instructions.

Branch predicting algorithms are extremely interesting. The early ones were very simple with:

Prediction: Never take the branch
OR
Prediction: Always take the branch

People soon realized that most branches were in loops, so they came up with a new algorithm

Prediction: If the last time we were here we took the branch, take it again, otherwise don't take it. Basically, repeat what we did the last time we ran this instruction.

IIRC there are lots of branch prediction algorithms, some of which are eerily accuratae (above 90%). Unforunately, branch prediction requires cache which takes away from the cache your programs need.

--
Thank you Mario! But our princess is in another castle!

Re:Branch Prediction by jbrandon · 2002-12-19 14:01 · Score: 5, Informative

Unforunately, branch prediction requires cache which takes away from the cache your programs need.

This notes that the branch prediction unit has some cache that is separate from the other cache. It also notes that the PIII BPU has the "eerily accurate" prediction success you describe.
Re:Branch Prediction by ottffssent · 2002-12-19 18:05 · Score: 4, Informative

All modern CPUs have highly accurate branch predictors. Just as caches need to catch the vast majority of memory accesses (About 98% I believe is a common number for the L1+L2 caches) for the CPU to work even remotely close to its theoretical maximum, branch predictors need to avoid pipeline flushes whenever possible. Consider the P4 with 20-odd stages, more in the FP pipeline. There could be dozens of instructions in flight by the time the branch test gets completed and says it took the wrong branch - The 20-stage pipeline needs to be emptied of invalid instructions, all of which get thrown away. A new memory location needs to be loaded, and execution needs to resume at that point. Extremely inefficient, so the occurence of this sort of thing has to be kept to an absolute minimum. Since the P4 suffers so horribly in the case of mispredicted branches, it tends to do poorly in branch-heavy code such as chess benchmarks. In order to keep such wasteful operations from happening, the CPU keeps track of thousands of previous branches in an attempt to guess correctly which way a new branch will go. There is a data structure in the CPU called the BHT, Branch History Table, that holds all this information, some times with many bits of info per branch.

I won't take the time to dig up references to see if any CPU architecture currently does all of these tricks, but consider all the things that can be done to minimize the impact of branches:
When a branch occurs, fetch instructions from *both* possible branch locations. Begin executing both sets of instructions in parallel, keeping the CPU's back-end busy. Flag these instructions with a "left branch" or "right branch" tag. When the branch test completes, toss out the wrong instructions and keep the good ones. Both branches will execute more slowly than a correctly-guessed branch that executes only one, but in the case of a mispredict, there is no pipeline flush, and no delay waiting for the PC to update and new instructions to flow in. Also, it's hard on the caches and RAM subsystem, since two sets of instructions rather than 1 need to be fetched.
Build a better predictor. By analyzing the type of branch and surrounding code, the branch predictor can get eerily accurate. Way better than 90%. A K6-2 could get 90% accuracy with no sweat, and that's a pretty old chip.
Prefetch. Grab the branch test and run it way ahead of the branch itself (when possible). If the outcome of the branch can be determined before the branch is reached (using instruction reordering trickery), there is effectively no branch at all. This can be "stacked" with other techniques as well.
I'm sure you can come up with several more. It's an interesting problem to think about, with most techniques having a good mix of benefits and drawbacks.

--
High-speed Road Trip (18.000KPH)

Holy Crap! by poshgoat · 2002-12-19 13:30 · Score: 5, Funny

I have a final exam on this stuff tomorrow morning... It would seem there is a God...!!

Re:Holy Crap! by Jucius+Maximus · 2002-12-19 14:02 · Score: 2, Informative

Heh, I was reading slashdot the night before I had my exam on this stuff as well (which was 2 weeks ago.)
Make sure you can identify RAW, WAW, and WAR hazards. (R == read, A == after, W == write)

Re:Ouch! by unicron · 2002-12-19 13:33 · Score: 3, Funny

Nice MS bash. Your karma pimp wants his money.

--
Finally, math books without any of that base 6 crap in them.

Re:Optimizing by PurpleFloyd · 2002-12-19 13:37 · Score: 5, Insightful

What if you just want to understand what your computer does "underneath the hood"? Slashdot has quite a few people reading it who feel this way; they tend to call themselves "geeks". While this might not be that useful to programmers in the course of their jobs, it might be useful to Slashdot's and Ars' audience: people who want to understand.

--

That's it. I'm no longer part of Team Sanity.

Re:Ouch! by medscaper · 2002-12-19 13:37 · Score: 2, Funny

Your karma pimp wants his money.

I'll have you know I have rolling credit, thank you. And I'm in VERY good standing.

Linux RULZ! MS SUCKS! Down with RIAA! Hilary Rosen is a dummy-head!

See?

--
Any sufficiently well-organized Government is indistinguishable from bullshit.

Great by Jenova · 2002-12-19 13:47 · Score: 3, Funny

Thanks for the links people. I really need this refresher course. Pipelining and superscalar execution are stuff I havent touch for quite a while :)

And you're a CS student?!!! by sparkz · 2002-12-19 13:50 · Score: 5, Interesting

I knew this before I did a BSc in CS; what I learned later, was the real stuff - how memory speed affects pipelining; memory has not got significantly faster in the past decade, where CPUs have gone from 30MHz to 3GHz. Therefore even more pipelines are required now, as we sit around, cycle upon cycle, waiting for memory to feed us some data.

In fact, Alan Cox gave a talk on this recently: UMeet2002.

--
Author, Shell Scripting : Expert Re

A request for a future Ars Technica story by Ross+Finlayson · 2002-12-19 14:01 · Score: 2, Funny

"Understanding why black text on a white background is easier to read than black text on a white background."

Re:A request for a future Ars Technica story by Ross+Finlayson · 2002-12-19 14:13 · Score: 3, Interesting

Oops, that should, of course be: "Understanding why black text on a white background is easier to read than *white* text on a *black* background."

That'll teach me for trying to make a snide comment :-)
Re:A request for a future Ars Technica story by TeknoHog · 2002-12-19 14:32 · Score: 2

> "Understanding why black text on a white background is easier to read than *white* text on a *black* background."
I don't understand this. Black on white is a historical remnant of ink-on-paper technology, and it has no basis in CRTs or LCDs. In fact I find black on white quite annoying, and irritating to my eyes, particularly on a CRT.
In a reflective LCD (no backlight), black on white might make more sense. In general I think the background (dominant color) should be the "neutral state", which is black on CRTs and white/gray on reflective LCDs.

--
Escher was the first MC and Giger invented the HR department.
Re:A request for a future Ars Technica story by hayden · 2002-12-19 16:15 · Score: 2

In general I think the background (dominant color) should be the "neutral state", which is black on CRTs and white/gray on reflective LCDs.
I don't think the neutral state is all that important. More important is that you aren't staring at a light all day trying to pick out dark bits. Light grey on black with muted colour highlights.
Not that this has anything to do with the Ars sight. They use white on black which is just as bad.

--
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
Re:A request for a future Ars Technica story by Gropo · 2002-12-19 18:55 · Score: 2

Oh good grief yeah... Whenever I tab back over to a white webpage after reading an Ars novella I suffer from heinous retinal burn. If it wasn't for the neat-o diagrams I'd just cut+paste :P

--
I hate Grammar Nazi's

Re:Optimizing by sparkz · 2002-12-19 14:05 · Score: 3, Informative

It is relevant to programmers - knowing how a CPU will pipleine your instructions can help in structuring a loop to be efficient; tied-in with this is caching strategies: how you read / write your data can have a huge impact on the program's performance.

I've posted the link earlier, but here it is again... Alan Cox recently gave an IRC talk: here.

--
Author, Shell Scripting : Expert Re

Enough with the bad analogies! by Wesley+Felter · 2002-12-19 14:22 · Score: 3, Interesting

Am I the only one who finds this stuff easier to understand when the author just explains what actually happens instead of using analogies? I thought the Hennessey & Patterson version of this was better, but then it wasn't free...

At last! by mao+che+minh · 2002-12-19 15:21 · Score: 4, Funny

Thank you! After suffering many long and terrible months under an oath of involuntary celibacy, this new found knowledge in superscalar execution is sure to win me a date with one of the many "cam girl amatuers" that have been offering me free services through email for months. Thank you for restoring my confidence. Now I must learn how to convey my thoughts without using run-on sentences.

Alpha Platform by AnonymousCowheard · 2002-12-19 16:39 · Score: 2, Funny

DEC designed the Alpha CPU to interface to the BUS and RAM over multiple pipelines. Their EV6 is the prime of their effort. EV7 is even better. Due to DEC's inability to attain loans and offset the high consumer cost to make Alpha more affordable, they were in a position to sell themselves to Compaq and their financial team followed. Compaq, same tradition, sold-out to Hewlet Packard and we all remember when HP's President declared HP will close its doors if the merger didn't complete. And now HP is *trying* to kill the Alpha at the ev7. Alpha is fastest in the market, and HP is also canceling its own in-house PA-RISC in favor of the much slower Intel Itanium2. Only company left with a license to produce Alpha hardware is Samsung and they've already dumped the technical details of their Alpha products from their website. This world stinks...Star Trek pulled off the air and now Alpha. Ode to Bankers for conspiracy and marketers for pushing inferior non-Alpha hardware.

--

But I'm sure you already Gnu that.

Re:Branch Prediction in PowerPC 970 by CyberDave · 2002-12-19 19:01 · Score: 3, Interesting

The forthcoming IBM PowerPC 970 CPU is supposed to have a very sophisticated branch prediction unit. (I'm not sure how it compares to that of the POWER4, from which the PPC 970 was derived, or how it compares to other CPUs, though.)

(Disclaimer: recalling all of this from memory based on the paper I wrote a few weeks ago on the PPC 970. Forgive me if I over-simply or mis-state something.)

The PPC 970 hast three branch history tables (BHTs). Each one has 16k (2^14) entries of one bit each. One BHT follows the more or less traditional method of tracking whether or not the branch prediction from a previous execution of the instrution was successful. One BHT has its entries associated with an 11-bit vector which tracks the last 11 instructions executed by the CPU (and using this to determine if the branch prediction was successful. The third and final BHT is used to determine which BHT has been more successful for the corresonding instructions. For each individual branch instruction, the third BHT is used to determine which method has had better success in the past and then that BHT is used as the branch prediction method for this execution of the instruction.

CyberDave

Slashdot Mirror

Understanding Pipelining and Superscalar Execution

33 of 87 comments (clear)