> The new microprocessors will be based on the Prescott 2M core that brings 2MB L2 cache, Intel EM64T, Enhanced Intel SpeedStep Technology (EIST) as well as Execute Disable Bit (EDB) capability. The chips will be clocked at 3.20GHz, 3.40GHz, 3.60GHz and 3.80GHz and will be intended for infrastructure supporting 800MHz Quad Pumped Bus and TDP of up to 115W.

X-bit labs - Hardware news - Intel Preps Onslaught with New Pentium 4
Processors 600
http://www.xbitlabs.com/news/cpu/dis...103132921.html

Trying to steal the thunder from Arnold, Yousuf Khan <(E-Mail Removed)> on Mon, 03 Jan 2005 17:10:53 -0500 spoke:

>> The new microprocessors will be based on the Prescott 2M core that brings 2MB L2 cache, Intel EM64T, Enhanced Intel SpeedStep Technology (EIST) as well as Execute Disable Bit (EDB) capability. The chips will be clocked at 3.20GHz, 3.40GHz, 3.60GHz and 3.80GHz and will be intended for infrastructure supporting 800MHz Quad Pumped
Bus and TDP of up to 115W.
>
>X-bit labs - Hardware news - Intel Preps Onslaught with New Pentium 4
>Processors 600
>http://www.xbitlabs.com/news/cpu/dis...103132921.html

I like THIS part....

>According to certain market sources, Intel’s Pentium 4 processors
>600-series are unlikely to offer much higher performance compared
>to today’s Intel Pentium 4 processors 500-series with similar core speeds.







--

The truth is out there,

but it's not interesting enough for most people.

Never anonymous Bud wrote:
> I like THIS part....
>
>
>>According to certain market sources, Intel’s Pentium 4 processors
>>600-series are unlikely to offer much higher performance compared
>>to today’s Intel Pentium 4 processors 500-series with similar core speeds.

Seems like adding more L2 cache is starting come its proverbial point of
diminishing returns.

Yousuf Khan

"Yousuf Khan" <(E-Mail Removed)> wrote in message
news:q7-dnZ7lfbUoT0TcRVn-(E-Mail Removed)...
>
> Seems like adding more L2 cache is starting come its proverbial
point of
> diminishing returns.

Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
over the previous 130nm generation. I've never heard an explanation
for this disaster. Yes, _doubled_. ;-(

On Tue, 04 Jan 2005 03:54:09 +0000, Felger Carbon wrote:

> "Yousuf Khan" <(E-Mail Removed)> wrote in message
> news:q7-dnZ7lfbUoT0TcRVn-(E-Mail Removed)...
>>
>> Seems like adding more L2 cache is starting come its proverbial
> point of
>> diminishing returns.
>
> Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
> over the previous 130nm generation. I've never heard an explanation
> for this disaster. Yes, _doubled_. ;-(

Did you ever find ot with certainty whether or not they added back in the
FXU multiplier and barrel-shifter? That issue still seems to be up in the
air.

--
Keith

Felger Carbon wrote:
> "Yousuf Khan" <(E-Mail Removed)> wrote in message
> news:q7-dnZ7lfbUoT0TcRVn-(E-Mail Removed)...
>
>>Seems like adding more L2 cache is starting come its proverbial
>
> point of
>
>>diminishing returns.
>
>
> Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
> over the previous 130nm generation. I've never heard an explanation
> for this disaster. Yes, _doubled_. ;-(

I wonder if it's got something to do with the doubled transistor count?
Twice the transistors to go through, twice the distance to travel
through. Even with a die shrink, it's still twice the distance per
transistor.

Yousuf Khan

Felger Carbon wrote:

> Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
> over the previous 130nm generation. I've never heard an explanation
> for this disaster. Yes, _doubled_. ;-(

Not quite.

Northwood = ~19 cycles
Prescott = ~28 cycles

L1 latency, however, I believe went from 2 to 4 cycles.

--
Regards, Grumble

On Tue, 04 Jan 2005 03:54:09 GMT, "Felger Carbon" <(E-Mail Removed)>
wrote:

(Outhouse-induced mangling fixed)

>"Yousuf Khan" <(E-Mail Removed)> wrote:
>>
>> Seems like adding more L2 cache is starting come its proverbial
>>point of diminishing returns.
>
>Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
>over the previous 130nm generation. I've never heard an explanation
>for this disaster. Yes, _doubled_. ;-(

Well, I think Yousuf is right about the diminishing returns of larger
cache size, as well. Seems to me the "paltry" 256k of a P3 serves
quite well for the job. The cost/performance trade-off of the huge
caches seems suspect, even if you don't factor-in things like latency
increases created by the larger cache size.

"keith" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
>
> > Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
> > over the previous 130nm generation. I've never heard an
explanation
> > for this disaster. Yes, _doubled_. ;-(
>
> Did you ever find ot with certainty whether or not they added back
in the
> FXU multiplier and barrel-shifter? That issue still seems to be up
in the
> air.

Yes, I did find out (honest), but I quickly lost interest in Prescott
when I discovered it did not increase performance over the previous
generation. So I am no longer certain, but I seem to remember that it
did include those improvements. But the performance improvement
provided by those two items is completely swamped by the lousy L2
latency.

Keith, if you ever discover _why_ the lousy L2 latency, please ping
me?

"Yousuf Khan" <(E-Mail Removed)> wrote in message
news:EgqCd.11354$P%(E-Mail Removed)...
> > Yousuf, the problem is that Prescott's L2 _doubled_ the L2 latency
> > over the previous 130nm generation. I've never heard an
explanation
> > for this disaster. Yes, _doubled_. ;-(
>
> I wonder if it's got something to do with the doubled transistor
count?
> Twice the transistors to go through, twice the distance to travel
> through. Even with a die shrink, it's still twice the distance per
> transistor.

Yousuf, if the cache transistor count is doubled the shrink will
result in L2 cache _area_ that's exactly the same as the old
generation, and hence the same distances. Sorry.