• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

3.2C vs 3.2E

mpegripper

[H]ard|Gawd
Joined
Oct 8, 2001
Messages
1,212
i haven't been keeping up to date on intel, i think the C and E are correct tho

i'm talking about the normal 800FSB versus the Prescott

which is better in terms of performance and heat at stock speeds and when overclocking?

this is gonna be in my rig in my sig below

TIA
 
The C is the better choice, its a bit cooler and a *bit* faster at stock speeds.

People ofter exaggerate how much faster the northwood is vs prescott.
 
They're the exact same price at newegg.com at this instant.

Despite the different cores, the 3.2E has a meg of L2 cache and the 3.2C has half a meg of cahce.

I think it's a bad idea to walk away from 512mB of L2 cache for the same price.

.B ekiM
 
This thread is a no brainer. Northwood all the way. It's signifigantly faster than the presscott. Since you dont have watercooling/phase change you'll almost certainly get higher a overclock on the northwood. Just a thought, if you do think you are gonna be OCing, you might wanna look into 3.0C's, they seem to overclock the best of the northwoods.
 
mikeblas said:
I think it's a bad idea to walk away from 512mB of L2 cache for the same price.
You may get an extra 512KB L2 and architectural improvements with Prescott but you also get a huge 31-stage pipeline that can severely impact performance in certain programs (games, 3D-rendering). So, Northwood is clock-for-clock faster, cooler, and looks like it overclocks better too (unless you own a Vapochill). My Northwood 3.2C hits 3.84GHz pretty easily using the stock Intel air cooler - how many Prescotts out there can boast that? Besides, at that kind of speed the Prescott would use so much juice it'd melt the mosfets right off your average mobo. :)
 
coz said:
a huge 31-stage pipeline that can severely impact performance in certain programs (games, 3D-rendering).

I keep hearing this, but I never get a good answer when I ask. So, I'll try again: Why is the longer pipeline worse for performance?

My understanding is that the pipeline gets flushed when there's a task swich. Does it relaly matter that more (or less) work gets flushed? What's the penalty, specifically?

.B ekiM
 
Well basically a longer pipeline allows for scaling of higher ghz, however, with a longer pipeline you get less efficiency because you're always having to try to fill the pipeline with work. The problem is most things don't fill up the pipeline which must be compensated through a faster clock rate, some would say things like Hyper Threading and even the larger cache. I can't remember a great analogy for this so I'll just say it's like an assemly line where if u have 15 workers who are almost always kept busy with work you get more output product. However, if you have 30 workers in the assembly line and half the time half of them are waiting for things to be done then it becomes less efficient.
Therefore if u look at the performance of the northwood and presscott and u think about all the added things in presscott like a new improved HT, 1mb l2 cache, better branch predictors, SSE3 it really seems to be compensating for the longer pipeline's inefficiency since both cpus perform relatively the same (minus heat and leakage issues). However, the pay off will be in a cpu that will eventually be able to clock higher, but this as many chip makers have learned is not an endless game.
Anyways, this was my poor attempt at clarifying your question. If you find this insufficient I'm sure many will be happy to elaborate.
 
mayakindaguy said:
The problem is most things don't fill up the pipeline

"Things" being instructions? Or streams of instructions? Or particular applications?

mayakindaguy said:
I can't remember a great analogy for this so I'll just say it's like an assemly line where if u have 15 workers who are almost always kept busy with work you get more output product. However, if you have 30 workers in the assembly line and half the time half of them are waiting for things to be done then it becomes less efficient.

How are you measuring efficiency? Certainly, if I'm paying their salaries, I don't want them to be earning money but not doing work for me.

What salary do I pay to a pipeline stage? What is it more than a shift register capable of holding an instruction and its operations? If a pipeline stage isn't used, what does it cost me?

mayakindaguy said:
Anyways, this was my poor attempt at clarifying your question. If you find this insufficient I'm sure many will be happy to elaborate.

Well, thanks for trying. And I'm sorry to be so dense about it -- it's just that I frequently see this conclusion drawn, and I'd like to come to understand the basis for the conclusion.

.B ekiM
 
mikeblas said:
"Things" being instructions? Or streams of instructions? Or particular applications?



How are you measuring efficiency? Certainly, if I'm paying their salaries, I don't want them to be earning money but not doing work for me.

What salary do I pay to a pipeline stage? What is it more than a shift register capable of holding an instruction and its operations? If a pipeline stage isn't used, what does it cost me?



Well, thanks for trying. And I'm sorry to be so dense about it -- it's just that I frequently see this conclusion drawn, and I'd like to come to understand the basis for the conclusion.

.B ekiM
Okay, let me just make it nice and simple for you. The longer the pipeline, the less work is done per clock cycle. Secondly, the longer the pipeline, the higher the penalty for brach misprediction is, instead of having to fill a 20 stage pipeline, you have to fill a 31 stage pipeline, which in turn takes more cpu cycles to do.
 
Liam said:
Okay, let me just make it nice and simple for you.

Well, that's the problem. There's no need to condescend. I can understand a complete answer, even if it's complicated. Stretched metaphors and oversimplifications aren't going to be helpful.

Liam said:
the higher the penalty for brach misprediction is, instead of having to fill a 20 stage pipeline, you have to fill a 31 stage pipeline, which in turn takes more cpu cycles to do.

Why does the pipeline have to be full before execution can continue?

.B ekiM
 
Big Worm said:
The C is the better choice, its a bit cooler and a *bit* faster at stock speeds.

People ofter exaggerate how much faster the northwood is vs prescott.

Having had both, I'd say that was true, the exaggeration part in particular. The Northwood would be his "safer" choice, since he mention overclocking. Provided he's feeling in a "safe mood". But then, when did this forum ever play anything safe.

Not a scientific observation here, but you seem to be leaning toward the Prescott. The only thing anyone can do is: make your own decision , and don't look back! Pipeline or not. Heat or not.

And it's all pretty good gear isn't it? All of It! Can remember reading this forum 4 years ago, no less, when reaching 1000mhz was OH! The shits! And so very,very, very, hard to do! And they pushed, didn't quit, on every forum. Until it was necessary to invent the P4 to break that magic 1000mhz.( Ok, so maybe they were going to do it anyway :rolleyes: ) But as fine as the PIII was, it couldn't achieve that. It had "flaws". So no one bought them?

Look at you people running 3.2mhz. 3.8mhz ..dual channel: balls to the walls! So that creates "heat", well ok. Hell, it's all good! Before the recent "quiet" PC thing... people had huge Alpha coolers and 27 case fans on a PIII 700 clocked to 933mhz!

It's bothersome to choose between a proven product such as Northwood and then The Prescott. And at the same price! But bothersome to go backwards too.

Great luck with your choice. Be happy with your choice. :) Either one will run, and none too shabby either. When you choose between C or E... just tell people: "you did it because you could." ;)
 
mikeblas said:
Well, that's the problem. There's no need to condescend. I can understand a complete answer, even if it's complicated. Stretched metaphors and oversimplifications aren't going to be helpful.

Why does the pipeline have to be full before execution can continue?

.B ekiM
I honestly dont know, I'm not an expert. Could someone who knows what they're talking about, in detail, step in?
 
Papa-Ming said:
Had these links still hanging around...

Thanks, PapaMing. The first link is interesting. It says that mispredicted branches are more expensive when the pipeline gets larger, but still doesn't explain why -- and, in fact, assumes that everyone came into the world with that knowledge.

The very next section of the article shows how the Prescott is substantially better than the Northwood at correctly predicting branches. It's always better for all tests in that Spec suite, except in one benchmark where it mispredicts 0.09 instructions per hundred, compared to the Northwood mispredicting 0.08 instructions per hundred.

The IA-32 Intel Architecture Optimization manual says that "Branch prediction is important to the performance of a deeply pipelined processor", and that "branch delay for a mispredicted branch can be many cycles, usually equivalent to the pipeline depth".

I'm still poking around in the Intel references, but I'll try to read your remaining references tonight, too.

.B ekiM
 
midpredicted branches are more expensive in a longer pipeline because u then have to trash all instruction sets thus wasting a clock cycle I believe. With a longer pipeline it takes longer for it to be filled with instruction sets again thus causing a greater penalty. The need for things like a larger l2 cache, much better branch prediction and an improved method of HT becomes crucial in minimalizing this penalty. However, in the end, the longer pipeline will allow for higher clock frequencies as Intel has always done just like with the northwood p4.
 
Unfortunately, PapaMing's last link was 404. This is a corrected link .

That article is more helpful than anything I've read so far, but there are still a few holes.

I think the first part of the problem was that I was confusing the pipeline with a prefetch queue. My 8088 heritage is hindering my Pentium knowledge acquisition.

But, once around that, I think I've got it:

The pipeline doesn't actually execute the instruction in question until nearly one of the last stages. Say it's stage 28 of 31 for the deeper pipeline, and that it's 17 of 20 for the shorter pipeline.

When the branch appeared at the beginning of the pipeline, prediction logic told the processor which opcodes to fetch. It did, and those ended up in the pipeline. 28 clock cycles (or 17 clock cycles) later, we find that the prediction was wrong; the conditional went the other way.

So we go to the correct instruction pointer and find the right opcode. The 27 (or 16) clock cycles that were used to keep pushing through the pipeline were wasted; they still execute, they can't be abandoned. They're retired as we start fetching and pipelining the correct instruction.

The reason the depeer pipeline is more expensive for a branch failure is because those 27 cycles were wasted -- or, because it'll be 27 cycles before we execute something useful again ... compared to 16 cycles for the shorter list.

.B ekiM
 
Back
Top