Pentium 4 pros and cons

OK... it looks like people here need a little explanation of how a pipeline works.

The common analogy is to think about washing your clothes. Doing this chore requires several steps. First you have to put clothes in the washer, and wait 30 minutes for the load to complete. Then you have to put the clothes in the dryer, and wait about 1 hour for them to dry. Then you have to sit down and fold them and put them away, which takes about 15 minutes. Every load of laundry that you do in this kind of example takes about 1 hour and 45 minutes.

However, consider an alternate example. Instead of waiting 1 hour for the dryer to complete its cycle, say you put another load in the washer, so that both things can go on at the same time. In addition, when it comes time to fold and put away the clothes, say you put additional loads in the washer and dryer. This way, everything is happening at the same time. It is much more efficient. Let's pretend you have as many loads of laundry as a processor has chunks of data (a lot of loads! https://www.sharkyforums.com/images/.../2005/06/5.gif). If this were the case, it would take you 1 hour for every load, instead of 1 hour and 45 minutes, because the dryer is the limiting factor. No matter how fast you fold your clothes and put them away, you still have to wait the hour for the dryer to finish. This is PIPELINING, but it's UNBALENCED. In this example, you have 3 pipeline stages: the washer, the dryer, and the folding. Let's take this one step further.

Suppose you didn't like waiting an hour for the dryer, and a 1/2 hour for the washer, so you bought new machines. Now you have 2 washers and 4 dryers, each spaced in time so that they finish in 15 minute intervals. Remember it takes you 15 minutes to finish folding and putting away your clothes, so if you have clothes being finished by at least one washer and one dryer every 15 minutes, then you have peak efficiency, and can get one load of laundry put away every 15 minutes. This is like having a 7-stage pipeline. It accounts for a 7x reduction in time than if you didn't do pipelining at all! This is called BALENCED PIPELINING.

I am speculating here, but in the Pentium 4, it may have been that the ALU was like the dryer in the above example. It was the limiting factor in an already balenced pipeline. By doubling the clock on the ALU unit, you have effectively made twice as many of them, and it's just like buying extra dryers.

Thus, if you were to only take 1 packet of data (just like one load of laundry), it would take you 20 clocks to get from one side of the pipe to the other. However, since processors have much more data than you have loads of laundry, there is usually 20 pieces of data; one in each of the pipeline stages. Thus, when the pipeline is operating at top efficiency, one piece of data will pop out on each of the Pentium 4's 1.5GHz clocks.

The problem, however, is that the pipe isn't always full. The analogy is that you accidently forgot and put a pen in your pants pocket, and did the laundry. You only notice your mistake when you get to the point where you fold your clothes. Now, all your clothes have turned blue, and you have to wash them all over again. It's time to take all the clothes out of all the machines, and start all over again. (Fortunately, you have bleech to get out the stains https://www.sharkyforums.com/images/.../2005/06/5.gif).

In the Pentium 4, the ink pen is the same as a branch misprediction. Like forgetting about your pen, it is rare, but it sure takes a lot of time to reverse the mistake. Fortunately, the Pentium 4 has an excellent branch predictor, so it's like searching your pockets for pens before putting them in the wash. Maybe you'll catch all the pens in your pants pockets, but you might miss a couple in your shirt pocket. OK... here the analogy starts to fall apart, but you get the idea.

The 20-stage pipeline allows for each stage to take the shortest amount of time, just like the above example only take 15 minutes to do a load of laundry. This allows for much higher clock speeds. But, every time a branch is mispredicted, for example, it takes a long time to fix everything, and performance will slow down. Overall, though, Intel is hoping that high clock speeds will eventually counteract the long pipeline penalty, and you will still get a faster processor.

Hope this helps you guys https://www.sharkyforums.com/images/.../2005/06/5.gif.

Arcadian,
You sure have a way with analgies, that is a great explanation, thanks for spending the time to show us the light.

Flip

Quote:

---

Originally posted by Flip:
Arcadian
Sorry, I didn't mean to sound like an idiot, I wasn't sure completely how it works, I just inferred a lot from what I had read, if you could point me to a good article explaining the 20 stage pipeline, it would be much appcreciated, or even better, if you gave me an explaination, I'd be very greatful!

Flip

p.s. no hard feelings? I'm pretty new at the deep down technical interworkings of the microchip.

---

Instead of re-inventing the wheel and writing a long post on pipelining I'll give you a ling to a discussion thread from a few months back on the topic. It starts of a G4 discussion but turns into one of the best Q&A on pipelining I have seen.
http://arstechnica.infopop.net/OpenT...74&m=224092771

Fun topic.

- 400MHz Front Side Bus

Nice improvement, but still well below what RISC workstations will be using. Not that X86 has ever had the memory bandwidth of RISC workstations, but they may be loosing ground. The Alpha EV7 for example will have 4 times the memory bandwidth of the P4.
This is probably an absolute minimum for a new processor given growing gap between processor and memory speed.

- Double Pumped Execution Units

I love this idea. If it scales it could be the most significant part of the architecture. It doubles you throughput and eliminates Read After Write (RAW) dependencies for instructions it applies to.

- Lack of Dual Processing at Launch

Not a big factor in my mind. Multi-processor is primarily used for servers and most IT shops will want to give the chip a while to stabilize before trusting anything important to it. PIII Xeons would likely be preferred to the P4 for some time yet.

- More than Double the Heat of Pentium III

Heat is not a concern for the end user. The chip either works or does not. It is up to the system builder to insure an appropriate thermal solution. The large die size should help this somewhat since it keeps the W/cm^2 about the same as the PIII. You won't see the P4 in notebooks any time soon though.

- Rambus Memory

DDR memory will be an option at some point. We don't know what will happen to the price of RDRAM if the P4 increases demand, but with Intel rebates current prices are competitive.

- High Bandwidth Caches

No kidding the bandwidth of the caches is high. The L1 D cache bandwidth is twice that of the PIII while the L2 bandwidth is more then the processor can use. The L2 can deliver 256 bits per clock while the L1 D cache is only 128 bits per clock and the (single) decoder is on 32 bits per clock. To add to the mystery (to me anyway) is that the L1 D cache is single ported, the load store unit is not double pumped but the AGU is. This may mean that the extra wide data path from the L1 gives something like the effect of a duel ported L1.
I'd be interested in any comment about this.

- 20-stage Pipeline / Branch Misprediction

A lot has been said about the longer pipeline lowering IPC. It may or may not, given the effect of better branch prediction and new branch hint instructions.
I'll go out on a limb and say that even if IPC is lowered it won't hurt overall performance, and here is why I think that. If you take two balanced pipelines, one 11 stages the other 22, if both do the same amount of work (same amount of logic) the 22 stage pipeline should clock twice as high. Lets say that the 11 stage pipeline can reach 1 GHz then the 22 stage should reach 2 GHz. Lets also assume that the branch penalty is 10 and 20 respectively.

If you work out the amount of time each pipeline is stalled by a branch mispredict it comes to exactly the same value. (10 ns) Both will sit idle for the same length of time on a mispredict, but the longer pipeline will be faster the rest of the time and therefor complete any given job more quickly. This only applies if the pipelines are balanced.

Again, any comments would be welcome.

I'll finish off in another post to keep this short (er) and somewhat readable.

Thanks for the long and interesting reply, Moridin. I wanted to touch on a few comments that you made.

Quote:

---

Originally posted by Moridin:
- High Bandwidth Caches

No kidding the bandwidth of the caches is high. The L1 D cache bandwidth is twice that of the PIII while the L2 bandwidth is more then the processor can use. The L2 can deliver 256 bits per clock while the L1 D cache is only 128 bits per clock and the (single) decoder is on 32 bits per clock. To add to the mystery (to me anyway) is that the L1 D cache is single ported, the load store unit is not double pumped but the AGU is. This may mean that the extra wide data path from the L1 gives something like the effect of a duel ported L1.
I'd be interested in any comment about this.

---

Hmm... I'm wondering what you're getting at here. Can you explain further, because your idea intrigues me.

I've noticed, too, that the cache bandwidth is almost TOO big for what the processor needs. Either they wanted to make sure the cache was the least of the bottlenecks, or Intel has something sneaky in mind https://www.sharkyforums.com/images/.../2005/06/6.gif.

Quote:

---

Originally posted by Moridin:
- 20-stage Pipeline / Branch Misprediction

A lot has been said about the longer pipeline lowering IPC. It may or may not, given the effect of better branch prediction and new branch hint instructions.
I'll go out on a limb and say that even if IPC is lowered it won't hurt overall performance, and here is why I think that. If you take two balanced pipelines, one 11 stages the other 22, if both do the same amount of work (same amount of logic) the 22 stage pipeline should clock twice as high. Lets say that the 11 stage pipeline can reach 1 GHz then the 22 stage should reach 2 GHz. Lets also assume that the branch penalty is 10 and 20 respectively.

If you work out the amount of time each pipeline is stalled by a branch mispredict it comes to exactly the same value. (10 ns) Both will sit idle for the same length of time on a mispredict, but the longer pipeline will be faster the rest of the time and therefor complete any given job more quickly. This only applies if the pipelines are balanced.

Again, any comments would be welcome.

---

I have the feeling that Intel was sort of aiming for bandwidth intensive programs, which would be somewhat latency tolerant. Programs that wait for user input (Word Processing) certianly do not need to get any faster, but programs like video encoding, 3D rendering, and background encryption/decryption would be very bandwidth intensive programs that will probably do well on the Pentium 4. It seems that the large number of pipeline stages was a tradeoff that was needed in order to reach the next generation of clock speeds, though I'm not sure a lot of the zealots on the boards will look at it that way at first.

Most people want immediate satisfaction in speed, and like you said, a lot of optimization is available, so we may have to wait for Pentium 4 to really get better programs written for it. I did not know that there was a Branch Hint instruction available, but that goes to show that optimizations are possible in programs, and that the Pentium 4 will probably not see these advantages at first. Also, SSE-2 needs to be optimized, as well as taking advantage of the Pentium 4's 128 byte cacheline boundaries.

Well, I'm a little off topic right now, but we should really spawn a discussion on optimizations.

Quote:

---

Originally posted by Moridin:
I'll finish off in another post to keep this short (er) and somewhat readable.

---

Please continue to post. I enjoy reading from you.

Quote:

---

Originally posted by Flip:
Arcadian,
You sure have a way with analgies, that is a great explanation, thanks for spending the time to show us the light.

Flip

---

Thanks... I appreciate the kind words. You know, I am happy to share my knowledge with everybody in this board, and actually it was one of the reasons I requested the Highly Technical Forum to be created. If you want me to write concerning a different topic, I would be interested in teaching you more.

Take care.

Another tutorial : ) http://www.hardwarecentral.com/hardw...orials/2427/1/

Quote:

---

Fortunately, the Pentium 4 has an excellent branch predictor, so it's like searching your pockets for pens before putting them in the wash.

---

What type of Branch Prediction is the P4 utilising,do you have a link to any info : )
F.Y.I
The K7 uses a 2,048-entry branch history table (BHT) with a simple two-bit Smith prediction algorithm. This predictor stands in sharp contrast to the K6's elaborate 8,192-entry BHT with its two-level GAs predictor, a feature that AMD now admits was overkill.

Quote:

---

Originally posted by OOAgentFiruz:
What type of Branch Prediction is the P4 utilising,do you have a link to any info : )

F.Y.I
The K7 uses a 2,048-entry branch history table (BHT) with a simple two-bit Smith prediction algorithm. This predictor stands in sharp contrast to the K6's elaborate 8,192-entry BHT with its two-level GAs predictor, a feature that AMD now admits was overkill.

---

I do indeed have a link for you https://www.sharkyforums.com/images/.../2005/06/5.gif. Here is a document that should answer a lot of your questions. It is by the Pentium 4 processor's lead architect, Doug Carmean.
http://www.intel.com/pentium4/download/nbarch.pdf

On Page 28, it says the following regarding the branch predictor of the Pentium 4.

"Accurate branch prediction is key to enabling longer pipelines"

"Dramatic improvement over P6 branch
predictor:
– 8x the size (4K)
– Eliminated 1/3 of the mispredictions"

"Proven to be better than all other
publicly disclosed predictors (g-share, hybrid, etc)"

You should read the rest of the document, too. It has a lot of information!

OOAgentFiruz, thanks for the link! That site should keep me busy for a while.

A little off the topic of the pipeline in PIV, but out of curiosity, are their technical limitations of socket 423? Why would Intel be changing the socket of the PIV so soon after it's release. Not to say that things cannot change but it is supposed to debut with the release of Foster? I do not understand this move.

Another question, will the PIV show a significant improvement with more memory bandwith, or will the dual RDRAM channel keep it happy. 3.2Gb/s is quite a bit. Looking for a flow chart for the 850 architecture as well. Any ideas?


Just a thought

------------------
Computers run on smoke....when it leaks out, you are in trouble.

Quote:

---

Originally posted by Phlux:
A little off the topic of the pipeline in PIV, but out of curiosity, are their technical limitations of socket 423? Why would Intel be changing the socket of the PIV so soon after it's release. Not to say that things cannot change but it is supposed to debut with the release of Foster? I do not understand this move.

---

Actually, you're not off topic at all. This topic deals with all the pros and cons of the Pentium 4 architecture and platform.

To answer your question, though, it could be any number of reasons why Intel is choosing to change sockets. One thing I do want to point out, though, is that I have yet to see an official press release stating that there will be a change in socket. The only things I have seen have been insubstantiated rumors, so I can't be sure that there will even be a change in socket. (I would really appreciate a link to verify this, if anybody has one).

Assuming that there is a change in socket, though, I would have to guess that it is probably for the following reason. Usually the same team that works on a product will not be the same team that works on that product's successor. I think that, because two different teams were working on Willamette (code name for Pentium 4) and Northwood (Pentium 4 on .13u shrink), that the requirements of the latter product was not received in time to be implemented in the first product. In other words, Willamette was being worked on first by one team, and they came up with a specification based on the requirements for the chip. Another team was working on Northwood, but before they came up with the requirements, the specification for socket 423 was probably already finished, so they created their own specification based on the new requirements. This is only my theory, but since miscommunication between the two groups can happen easily, it is a possibility.

Quote:

---

Originally posted by Phlux:
Another question, will the PIV show a significant improvement with more memory bandwith, or will the dual RDRAM channel keep it happy. 3.2Gb/s is quite a bit. Looking for a flow chart for the 850 architecture as well. Any ideas?

Just a thought

---

RDRAM gives the Pentium 4 the same memory bandwidth as the front side bus bandwidth. Both interfaces allow for 3.2GB/s, and that allows for optimal transfers. It is doubtful that a different amount of memory bandwidth could allow for a better performance. My opinion is that DDR memory may in fact reduce the performance of the Pentium 4, since the bandwidth for PC2100 is only 2.1GB/s. Of course, we will have to wait until there are Pentium 4 boards with different memory interfaces to compare the two.

Also, the flow chart for the i850 will probably be very similar to other Intel chipsets, with the only exception being the dual memory interfaces.

Quote:

---

Originally posted by Arcadian:
[B]Hmm... I'm wondering what you're getting at here. Can you explain further, because your idea intrigues me.B]

---

I'm not quite sure either. It's just that some things don't look like they should. The AGU is double pumped, so the processor can generate addresses for two loads/stores each clock cycle. The Load Store unit is not double pumped so it can only actually perform one load per clock. If the D cache was duel ported the processor could perform 2 load/stores per cycle just like the Alpha and Athlon but it is not (apparently there are a number of restrictions in the Athlon duel ported cache)

At the same time the D cache data path is twice as wide as it should be. Why would you have a 128 bit wide data paths to the L1 data cache when you can only load 32 bit integers and 64 bit floating point values?

There are a couple of possible answers. The first would be that that the 128-bit data path could be associated with SSE2, and the AGU is double pumped so that the address is ready 1/2 clock cycle sooner giving your cache extra time to return a value. I think this may be too much coincidence. Why would you have an AGU and D cache data paths that can support loading 2 64-bit numbers and build a load store unit that can only load 1 64 bit number.

Another more intriguing answer would be that the P4 can load/store 2 values per clock as long as the values were in the same 128-bit section of memory.

Or maybe Intel has some surprise in store for us.

The only reason I can think of for having the L2 bandwidth that the P4 does is so that L1 line fills occur more quickly. This would reduce latency if you had to loads that occur near each other that miss L1 and hit L2. The P4 L2 can fill the 128 Byte cacheline in 4 cycles, so you may save a few cycles of latency on occasion. My question is if this is enough to justify the L2 bandwidth.

As I said before, the P4 L2 has nearly twice as bandwidth as the core can use, so there may be something strange here as well.

I have a few minutes so I'll try to cover my opinions on a few more points.

- High Clock Frequencies

High clock frequencies are a very good thing, not everything but probably the most important. A lot of people around the web like to say clock speed is not everything and then infer that IPC is. I disagree with this, especially in X86.
The limited number of registers in the X86 architecture mean that it has to perform a lot of loads and stores compared to other architectures. IMHO this tends to make the code more linear and less suitable for executing a lot of instructions in parallel. The loads cause an even bigger problem since you can't perform calculations on data that you do not have yet. Limitations on how you can reorder loads and stores make the instruction stream even more linear.

All this combines to make it much more difficult to get IPL out of the X86 architecture compared to other newer architectures. You can get around some of this by using low latency caches, large OOO windows, and even by reducing Read after write dependencies (all of which the P4 has) but in the longer term the only way of increasing performance beyond a certain level is increasing clock speed.

(Ok more registers would be the real long-term answer but that would likely require new modes, OS support, and rewriting software. AMD has the right idea here in combining this change with the move to 64 bits. I'm not sure if AMD can get the market support this would require though, especially when you consider how long the move from 16 to 32 bits has taken and that is not even done yet.)

Higher clock frequencies have other good effects as well. Even where the P4 has increased latencies and stalls in terms of clock cycles the real latency (and performance lost) in terms of time is likely reduced because each clock cycle is shorter.

- Higher Clock Frequencies in the Future

It should be apparent by now that I think the P4 will prove to be much better than many people think. I think Intel has done an excellent job of targeting it to its intended market over its entire life span, and I think this is another example.

The pipeline of the P4 apparently has several stages with NO logic whatsoever. This is to allow signals to travel form one part of the chip to another. Now, this is a large chip, but not that large. The die itself will likely be 40 % wider and 40 % longer then the PIII, so it is unlikely that any wires are more then 40 % longer and in fact if Intel has done a really good layout job the wires may not be any longer then the PIII. So why do you need these "Drive" stages in the pipeline?

I think they are there to accommodate changes in process technology over the next few years. Right now we are on the verge of a fundamental change in the way processors speed reacts to a die shrink. A process shrink speeds up transistors, but not the wires. Up till now this has not mattered much since the wires were much faster then the transistors. We have now reached the point where the speed of the wires is often more important then transistor speed. Cu wires and SOI act as a one time speed up for the wires but this only pushes back the problem a little, it does not solve it.

I think these "Drive" stages will make the P4 much more scalable on future process shrinks then processors that do not have this type of a stage. In other words I think the P4 will get a better clock boost going from .13 Cu process to a .1 Cu (and smaller) process relative to the Athlon of PIII. It should also make it less sensitive to running on a .18 Al process, so don't be surprised if the PIII moves to .13 Cu before the P4.

Well I think that’s enough for one post, again any comments would be welcome.

Quote:

---

Originally posted by Moridin:
I'm not quite sure either. It's just that some things don't look like they should. The AGU is double pumped, so the processor can generate addresses for two loads/stores each clock cycle. The Load Store unit is not double pumped so it can only actually perform one load per clock. If the D cache was duel ported the processor could perform 2 load/stores per cycle just like the Alpha and Athlon but it is not (apparently there are a number of restrictions in the Athlon duel ported cache)

At the same time the D cache data path is twice as wide as it should be. Why would you have a 128 bit wide data paths to the L1 data cache when you can only load 32 bit integers and 64 bit floating point values?

There are a couple of possible answers. The first would be that that the 128-bit data path could be associated with SSE2, and the AGU is double pumped so that the address is ready 1/2 clock cycle sooner giving your cache extra time to return a value. I think this may be too much coincidence. Why would you have an AGU and D cache data paths that can support loading 2 64-bit numbers and build a load store unit that can only load 1 64 bit number.

Another more intriguing answer would be that the P4 can load/store 2 values per clock as long as the values were in the same 128-bit section of memory.

Or maybe Intel has some surprise in store for us.

The only reason I can think of for having the L2 bandwidth that the P4 does is so that L1 line fills occur more quickly. This would reduce latency if you had to loads that occur near each other that miss L1 and hit L2. The P4 L2 can fill the 128 Byte cacheline in 4 cycles, so you may save a few cycles of latency on occasion. My question is if this is enough to justify the L2 bandwidth.

As I said before, the P4 L2 has nearly twice as bandwidth as the core can use, so there may be something strange here as well.

---

Well, you certainly seem to know a lot about the Pentium 4 architecture, Moridin! I was wondering about what you said, and it struck me that one possibility is that Intel included these high bandwidths for future tweaking inside the core.

Maybe they wanted some features that weren't able to be implemented on time, so they left room to implement them in a future P7 microarchitecture. Perhaps Foster or Northwood will include some surprises.

I have a few questions fot you, though. What do you think is the impact on these specs for the L3 cache that Foster is reported to have? Also, how would these specs allow for future technologies, such as multithreading, to be implemented in some later P7 based processor?

Again, thanks for the response. https://www.sharkyforums.com/images/.../2005/06/5.gif

PS... I've been meaning to ask you about your screen name. I am playing Baldur's Gate 2, and if you attack dwarves, they will shout, "By Moridin's Hammer!" Just wondering if that's where you got the name from (not the game, but the same mythical reference that the game is using).