Prescott problems enumerated

[Felger Carbon]

Boy, did I blow it big on Prescott. Because clock speeds always
doubled with a design-rules shrink, I thought Prescott would, too.
Because performance always went up when the transistor count
dramatically increased, I thought Prescott would, too. Because
performance always went up when v.0 of an architecture has some
problems fixed by v.1, I thought Prescott would, too. Silly me.

So until now I've (understandably) been quiet about Prescott. ;-)

But I've been keenly following the various Prescott threads on this
NG, and have seen _many_ suggestions why Prescott sucks. I think it's
time they be enumerated all together. Consider this a "first cut",
and feel free to add to this list, please!

1. On-chip cache latencies almost doubled.
2. Pipeline count increased from 20 to 30.
3. 64-bit capability was added.
4. Low priority, low funding, and unskilled engineers may have been
assigned.
5. Intel may have _wanted_ Prescott to look bad, esp. vs Itanium.
6. Fundamental physics rose up and swatted Prescott on the nose.

 

[Robert Myers]

Boy, did I blow it big on Prescott. Because clock speeds always
doubled with a design-rules shrink, I thought Prescott would, too.
Because performance always went up when the transistor count
dramatically increased, I thought Prescott would, too. Because
performance always went up when v.0 of an architecture has some
problems fixed by v.1, I thought Prescott would, too. Silly me.

So until now I've (understandably) been quiet about Prescott. ;-)

But I've been keenly following the various Prescott threads on this
NG, and have seen _many_ suggestions why Prescott sucks. I think it's
time they be enumerated all together. Consider this a "first cut",
and feel free to add to this list, please!

1. On-chip cache latencies almost doubled.
2. Pipeline count increased from 20 to 30.
3. 64-bit capability was added.

Meaning, I think, that, as many had expected, Intel had that burden
built into the original design, even though they didn't own up to it
until well after Prescott was released. Does anybody know for sure?

4. Low priority, low funding, and unskilled engineers may have been
assigned.
5. Intel may have _wanted_ Prescott to look bad, esp. vs Itanium.
6. Fundamental physics rose up and swatted Prescott on the nose.

7. Intel apparently didn't have as good a handle on their process
technology as they thought.

My number seven overlaps with your number six, but I'd recognize a
distinction between not being able to solve a problem and not knowing
you are unable to solve a problem. They were still trying to fix
process after Prescott was presented at IDF (but before it nominally
went on the market).

RM

 

[George Macdonald]

Meaning, I think, that, as many had expected, Intel had that burden
built into the original design, even though they didn't own up to it
until well after Prescott was released. Does anybody know for sure?

I always thought the "clues for Yamhill" article, and its bit-slice nature,
here www.chip-architect.com were utterly convincing. Note that Intel was
still denying the existence of Yamhill until ~the end of 2003. There was
even a (cross-)poster in this NG who works for Intel who trashed the whole
idea - no skunk works existed for it.

7. Intel apparently didn't have as good a handle on their process
technology as they thought.

My number seven overlaps with your number six, but I'd recognize a
distinction between not being able to solve a problem and not knowing
you are unable to solve a problem. They were still trying to fix
process after Prescott was presented at IDF (but before it nominally
went on the market).

There were also similar issues with Dothan. The things is: who at Intel
couldn't grasp the above? There must have been some who knew the truth but
had to "disagree & commit". For that matter, how do you tell/convince a
policy maker that his roadmap is incompatible with the realities of
physics? How do you wrest control of the asylum from the lunatics?

 

[keith]

I don't think that one is exactly true.

Take a peek at the chart here:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2353&p=2

The L1 latency has doubled, but the L2 has gone from 16 clocks to 23.

Ok, not "exactly", but damned close enough to "double" for the sake of
performance.

And look at the numbers for the Pentium M: 3 clocks L1 and 10
clocks L2!

Ok, now look at time (cycles times 1/f). Is it any wonder tha P3 lives
on?

No matter what RM thinks, Intel has stepped on a turd.

 

[Yousuf Khan]

But I've been keenly following the various Prescott threads on this
NG, and have seen _many_ suggestions why Prescott sucks. I think it's
time they be enumerated all together. Consider this a "first cut",
and feel free to add to this list, please!

1. On-chip cache latencies almost doubled.
2. Pipeline count increased from 20 to 30.
3. 64-bit capability was added.
4. Low priority, low funding, and unskilled engineers may have been
assigned.

4a. They used an automated circuit-laying program which doubled the size
of an already huge core. Basically, used templates to design this thing.

5. Intel may have _wanted_ Prescott to look bad, esp. vs Itanium.

You can do that using bad memory timings on chipsets and stuff. No need
to cripple the CPU itself.

6. Fundamental physics rose up and swatted Prescott on the nose.

Yup. The biggest one.

Yousuf Khan

 

[nobody]

4a. They used an automated circuit-laying program which doubled the size
of an already huge core. Basically, used templates to design this thing.


You can do that using bad memory timings on chipsets and stuff. No need
to cripple the CPU itself.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yousuf, I have to respectfully disagree with you on this one. No
matter how marginal in Intel world, VIA, ATI, SIS, and recently Nvidia
are there. Imagine how would INTC look with crippled chipsets in
comparison to the alternatives, and how Intel-only Dell would be
yelling and screaming because of that - or maybe deserting to
alternative chipset or (gulp!) alternative CPU. And don't forget A64
is out there, not at all crippled in comparison to Opteron (unless you
count SMP capability).

 

[Rob Stow]

I don't think that one is exactly true.

Take a peek at the chart here:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2353&p=2

The L1 latency has doubled, but the L2 has gone from 16 clocks to 23.

And look at the numbers for the Pentium M: 3 clocks L1 and 10
clocks L2!

 

[chrisv]

Take a peek at the chart here:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2353&p=2

The L1 latency has doubled, but the L2 has gone from 16 clocks to 23.

And look at the numbers for the Pentium M: 3 clocks L1 and 10
clocks L2!

I'm wondering about the Northwood's L1 latency of 1 or 2 clocks,
depending on the benchmaek used. Is that to be believed?

 

[George Macdonald]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yousuf, I have to respectfully disagree with you on this one. No
matter how marginal in Intel world, VIA, ATI, SIS, and recently Nvidia
are there. Imagine how would INTC look with crippled chipsets in
comparison to the alternatives, and how Intel-only Dell would be
yelling and screaming because of that - or maybe deserting to
alternative chipset or (gulp!) alternative CPU. And don't forget A64
is out there, not at all crippled in comparison to Opteron (unless you
count SMP capability).

Dell used to use Serverworks chipsets in their big MP boxes - dunno what
their plans are now but obviously Intel seems to have a better offering of
server chipsets currently. If IBM's Hurricane turns out to match
expectations it could leave Dell with a problem in server space.

As for crippled Intel chipsets, their not usually crippled through
incompetence... rather through market segmenation "plans" - case in point:
the i925 is limited to 32-bit addressing. We'll see how things play out in
the next chipset, considering that EM64T is now available in desktop P4s.