Sign in with
Sign up | Sign in
Your question

The coming of the Pentium 4 600-series

Last response: in CPUs
Share
Anonymous
a b à CPUs
January 3, 2005 8:10:53 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

> 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/display/20050103132921...
Anonymous
a b à CPUs
January 3, 2005 9:18:13 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

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
Anonymous
a b à CPUs
January 4, 2005 6:54:09 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:q7-dnZ7lfbUoT0TcRVn-sw@rogers.com...
>
> 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_. ;-(
Related resources
January 4, 2005 6:54:10 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

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

> "Yousuf Khan" <bbbl67@ezrs.com> wrote in message
> news:q7-dnZ7lfbUoT0TcRVn-sw@rogers.com...
>>
>> 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
Anonymous
a b à CPUs
January 4, 2005 6:54:10 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Felger Carbon wrote:
> "Yousuf Khan" <bbbl67@ezrs.com> wrote in message
> news:q7-dnZ7lfbUoT0TcRVn-sw@rogers.com...
>
>>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
Anonymous
a b à CPUs
January 4, 2005 11:33:59 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Tue, 04 Jan 2005 03:54:09 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:

(Outhouse-induced mangling fixed)

>"Yousuf Khan" <bbbl67@ezrs.com> 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.
Anonymous
a b à CPUs
January 4, 2005 4:41:23 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

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
Anonymous
a b à CPUs
January 5, 2005 1:20:22 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.01.04.04.08.22.865079@att.bizzzz...
>
> > 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?
Anonymous
a b à CPUs
January 5, 2005 1:20:23 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:EgqCd.11354$P%3.1017059@news20.bellglobal.com...
> > 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.
January 5, 2005 1:46:33 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Tue, 04 Jan 2005 22:20:22 +0000, Felger Carbon wrote:

> "keith" <krw@att.bizzzz> wrote in message
> news:p an.2005.01.04.04.08.22.865079@att.bizzzz...
>>
>> > 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?

You keep your ear to the same rumors I do. I certainly am not likely to
see any such information "officially". Since Andy gave me a copy of his
book, we haven't talked much. ;-)

--
Keith
Anonymous
a b à CPUs
January 5, 2005 2:27:16 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Felger Carbon wrote:
> "Yousuf Khan" <bbbl67@ezrs.com> wrote in message
> news:EgqCd.11354$P%3.1017059@news20.bellglobal.com...
>
>>>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.
>
>

And it must be mentioned that with a 130 nm process AMD went
from: 256 KB L2 Pre-Barton Athlon XP's, L2 latency = 28 clocks
to: 512 KB L2 Barton Athlon XP L2 latency = 23 clocks
to: 1024 KB L2 AMD64 L2 latency = 20 clocks

No idea what is going to happen to the L2 latency on the 90 nm AMD64 chips.
I've heard that both cache management and the memory controller have
been tweaked, but I haven't read any latency numbers.
Anonymous
a b à CPUs
January 5, 2005 7:35:09 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

chrisv wrote:
> On Tue, 04 Jan 2005 03:54:09 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
> wrote:
>
> (Outhouse-induced mangling fixed)
>
>
>>"Yousuf Khan" <bbbl67@ezrs.com> 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.
>
The large cache size really helps reduce bus contention in SMP
configurations. It feels as though lower latency would be better than
size at these low speeds, but I bet Intel did simulations and chose more
over faster. Why they had to choose I can't even guess!

--
bill davidsen (davidsen@darkstar.prodigy.com)
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com
Anonymous
a b à CPUs
January 5, 2005 11:58:55 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Tue, 04 Jan 2005 22:20:23 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:

>"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
>news:EgqCd.11354$P%3.1017059@news20.bellglobal.com...
>> > 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.

But skinnier wires and thus inferior RC characteristics, possibly?
Anonymous
a b à CPUs
January 5, 2005 4:27:07 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <l30ot0loajbmitvv7eijtf0ms5j1mbjepe@4ax.com>,
chrisv@nospam.invalid says...
> On Tue, 04 Jan 2005 22:20:23 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
> wrote:
>
> >"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
> >news:EgqCd.11354$P%3.1017059@news20.bellglobal.com...
> >> > 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.
>
> But skinnier wires and thus inferior RC characteristics, possibly?

Or they tool the old macros, plopped down twice as many and wired them
up with whatever glue they needed to get it to work. That would
account for perhaps two clocks (maybe more with the tags), but the
rest???

--
Keith
Anonymous
a b à CPUs
January 5, 2005 5:04:06 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Bill Davidsen" <davidsen@darkstar.prodigy.com> wrote in message
news:18KCd.5034$lZ5.2442@newssvr31.news.prodigy.com...
> The large cache size really helps reduce bus contention in SMP
> configurations. It feels as though lower latency would be better
than
> size at these low speeds, but I bet Intel did simulations and chose
more
> over faster. Why they had to choose I can't even guess!

Amen, bro! ;-)
Anonymous
a b à CPUs
January 8, 2005 4:23:00 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Felger Carbon wrote:
> "keith" <krw@att.bizzzz> wrote in message
> news:p an.2005.01.04.04.08.22.865079@att.bizzzz...
>>
>>> 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?

Remember that the L1 latency in Prescott is stupidly high as well

if they could tweak the L1/L2 latencies back down to Northwood levels, it'd
probably start being a very very impressive chip, even with it's stupidly
high power needs.


-JB
!