Sign in with
Sign up | Sign in
Your question

details about dual-core Yonah emerge

Last response: in CPUs
Share
Anonymous
a b à CPUs
June 2, 2005 8:11:55 PM

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

Looks like it will contain a shared L2 cache, but no 64-bit yet. No
64-bit until "the market requires it". Sort of like what kept Windows
x64 from coming out until now; but now that x64 is already out, not
sure how Intel can prevent the market from requiring it anymore.

Intel spills beans on Yonah, the next notebook chip | CNET News.com
http://news.com.com/Intel+spills+beans+on+Yonah%2C+the+...

Yousuf Khan
Anonymous
a b à CPUs
June 3, 2005 4:52:05 AM

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

"YKhan" <yjkhan@gmail.com> wrote in message
news:1117753915.086516.302940@g14g2000cwa.googlegroups.com...
> Looks like it will contain a shared L2 cache, but no 64-bit yet. No
> 64-bit until "the market requires it". Sort of like what kept
Windows
> x64 from coming out until now; but now that x64 is already out, not
> sure how Intel can prevent the market from requiring it anymore.

Yousuf, I thought Celerons were now routinely shipping with x64
enabled. *If* that's right, there must be something else blocking x64
from Yonah.
Anonymous
a b à CPUs
June 3, 2005 3:09:11 PM

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

Jason Gurtz wrote:
> On 6/2/2005 20:52, Felger Carbon wrote:
>
> > enabled. *If* that's right, there must be something else blocking x64
> > from Yonah.
>
> More than likely there'd be more power draw; definitely a no-no in a
> laptop. This thing sure looks like it'll be a real screamer.
>
> From everything I've seen it looks like longhorn will be fully supported
> in 32bit and x64 flavors so I don't really see lack of this feature as too
> big a deal. Only another year and a half or so to merom...
>


I agree. The question isn't just when will 64 bit software be
available, but when will 32 bit software *not* be available. I think it
will be a while before having a 64 bit notebook with greater than 4gb
ram is a necessity.

With all the existing 32bit systems in the world right now it might be
a decade or more before you absolutely can't buy a given app or OS in
32bit flavor.
Related resources
Anonymous
a b à CPUs
June 3, 2005 5:00:46 PM

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

On 6/2/2005 20:52, Felger Carbon wrote:

> enabled. *If* that's right, there must be something else blocking x64
> from Yonah.

More than likely there'd be more power draw; definitely a no-no in a
laptop. This thing sure looks like it'll be a real screamer.

From everything I've seen it looks like longhorn will be fully supported
in 32bit and x64 flavors so I don't really see lack of this feature as too
big a deal. Only another year and a half or so to merom...

~Jason

--
Anonymous
a b à CPUs
June 3, 2005 5:56:28 PM

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

Felger Carbon wrote:
> Yousuf, I thought Celerons were now routinely shipping with x64
> enabled. *If* that's right, there must be something else blocking x64
> from Yonah.

Hard to say, well the Celeron-D's are of course based off of the
Prescott core which already has x64.

Another possibility is that it seems like the Netburst chips are like
old American V8 car engines from the 50's and 60's. There wasn't a lot
of subtlety built into those things, and there was lots of room for
aftermarket improvement. You could drop a 64-bit module into the
Netburst like you could drop a bigger carb into one of those old
engines. But the Pentium M is like a highly integrated European engine,
where changing even a small pipe might throw it's balance off. Just my
speculation.

Yousuf Khan
Anonymous
a b à CPUs
June 4, 2005 1:08:27 AM

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

Jason Gurtz wrote:
> On 6/2/2005 20:52, Felger Carbon wrote:
> More than likely there'd be more power draw; definitely a no-no in a
> laptop. This thing sure looks like it'll be a real screamer.

Why do you think 64-bit would require more power draw?

Yousuf Khan
Anonymous
a b à CPUs
June 4, 2005 1:58:17 PM

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

On Fri, 03 Jun 2005 00:52:05 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
wrote:

>"YKhan" <yjkhan@gmail.com> wrote in message
>news:1117753915.086516.302940@g14g2000cwa.googlegroups.com...
>> Looks like it will contain a shared L2 cache, but no 64-bit yet. No
>> 64-bit until "the market requires it". Sort of like what kept
>Windows
>> x64 from coming out until now; but now that x64 is already out, not
>> sure how Intel can prevent the market from requiring it anymore.
>
>Yousuf, I thought Celerons were now routinely shipping with x64
>enabled. *If* that's right, there must be something else blocking x64
>from Yonah.
>

Not Pentium-M architecture, though--one guesses that Intel just
doesn't have 64-bit designed in.

I'd agree, though that Intel is up to something here, other than
design costs.

RM
Anonymous
a b à CPUs
June 4, 2005 5:19:45 PM

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

>
> I agree. The question isn't just when will 64 bit software be
> available, but when will 32 bit software *not* be available. I think it
> will be a while before having a 64 bit notebook with greater than 4gb
> ram is a necessity.
>
> With all the existing 32bit systems in the world right now it might be
> a decade or more before you absolutely can't buy a given app or OS in
> 32bit flavor.

yeah but since when does the consumer care about stuff like that, all a
sales guy has to say is this laptop is 32bit while the amd over there is
64 and they will take the higher number.

it may not be a real issue but when you have two like priced processors
and one wouln't run a lot of major software i recon it will have trouble.
June 5, 2005 3:23:25 AM

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

On Sat, 04 Jun 2005 09:58:17 -0400, Robert Myers
<rmyers1400@comcast.net> wrote:

>On Fri, 03 Jun 2005 00:52:05 GMT, "Felger Carbon" <fmsfnf@jfoops.net>
>wrote:
>
>>"YKhan" <yjkhan@gmail.com> wrote in message
>>news:1117753915.086516.302940@g14g2000cwa.googlegroups.com...
>>> Looks like it will contain a shared L2 cache, but no 64-bit yet. No
>>> 64-bit until "the market requires it". Sort of like what kept
>>Windows
>>> x64 from coming out until now; but now that x64 is already out, not
>>> sure how Intel can prevent the market from requiring it anymore.
>>
>>Yousuf, I thought Celerons were now routinely shipping with x64
>>enabled. *If* that's right, there must be something else blocking x64
>>from Yonah.
>>
>
>Not Pentium-M architecture, though--one guesses that Intel just
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which is not much more than just another incarnation of old good P6
architecture, that started as PPro around 1995, IIRC. At that time,
16 bit was the king, and it was not too far away from the (in)famous
B.G. blurp about 640k RAM being enough for everyone. 4 GB was the
number not yet passed by mainstream harddrives. Nobody even thought
about 64 bit back then...
>doesn't have 64-bit designed in.
>
>I'd agree, though that Intel is up to something here, other than
>design costs.
>
>RM
Anonymous
a b à CPUs
June 5, 2005 5:25:41 PM

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

nobody@nowhere.net wrote:
>>Not Pentium-M architecture, though--one guesses that Intel just
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Which is not much more than just another incarnation of old good P6
> architecture, that started as PPro around 1995, IIRC. At that time,
> 16 bit was the king, and it was not too far away from the (in)famous
> B.G. blurp about 640k RAM being enough for everyone. 4 GB was the
> number not yet passed by mainstream harddrives. Nobody even thought
> about 64 bit back then...

What are you talking about? 32-bit was around for at least ten years
prior to that, with the 386 in 1985. The P6 architecture was about the
fourth generation of 32-bit chips in the x86 line: 386, 486, Pentium P5,
and Pentium P6. Pentium 4 represents the fifth generation of 32-bit, and
Intel's first generation of x64.

Yousuf Khan
Anonymous
a b à CPUs
June 5, 2005 10:06:12 PM

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

nobody@nowhere.net wrote:
> I am only remembering the times when was released P6 core, the one on
> which Pentium M is largely based.
> Software-wise, it was the year of the first consumer-level OS (win95)
> introduction (marginal players like Mac, PS/2 etc. didn't count much).
> Even that was largely 16 bit DOS with some 32 bit extensions on top of
> it. More so, corporate desktops also were mostly DOS/WIN3.x, with
> NT3.51 and flavors of *NIX being marginal players, until the
> introduction of NT4.0 about a year later. The ability of 386 to run
> 32 bit code mostly went unused.

I don't think it was quite as primitive back then as you think it was.

> My point is - back then nobody seriously thought about 64-bitness, and
> this is what makes near impossible to tack AMD64 onto P6-based PM core
> developed around that time.

Yet, they were able to add all kinds of power management circuitry into
this core, which it was not originally designed to take either.

Yousuf Khan
June 6, 2005 3:29:51 AM

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

On Sun, 05 Jun 2005 13:25:41 -0400, Yousuf Khan <bbbl67@ezrs.com>
wrote:

>nobody@nowhere.net wrote:
>>>Not Pentium-M architecture, though--one guesses that Intel just
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Which is not much more than just another incarnation of old good P6
>> architecture, that started as PPro around 1995, IIRC. At that time,
>> 16 bit was the king, and it was not too far away from the (in)famous
>> B.G. blurp about 640k RAM being enough for everyone. 4 GB was the
>> number not yet passed by mainstream harddrives. Nobody even thought
>> about 64 bit back then...
>
>What are you talking about? 32-bit was around for at least ten years
>prior to that, with the 386 in 1985. The P6 architecture was about the
>fourth generation of 32-bit chips in the x86 line: 386, 486, Pentium P5,
>and Pentium P6. Pentium 4 represents the fifth generation of 32-bit, and
>Intel's first generation of x64.
>
> Yousuf Khan
I am only remembering the times when was released P6 core, the one on
which Pentium M is largely based.
Software-wise, it was the year of the first consumer-level OS (win95)
introduction (marginal players like Mac, PS/2 etc. didn't count much).
Even that was largely 16 bit DOS with some 32 bit extensions on top of
it. More so, corporate desktops also were mostly DOS/WIN3.x, with
NT3.51 and flavors of *NIX being marginal players, until the
introduction of NT4.0 about a year later. The ability of 386 to run
32 bit code mostly went unused.
My point is - back then nobody seriously thought about 64-bitness, and
this is what makes near impossible to tack AMD64 onto P6-based PM core
developed around that time.
Anonymous
a b à CPUs
June 6, 2005 4:57:07 PM

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

Jason Gurtz wrote:
> Wasn't the P6 the first 32-bit generation that was much more efficient at
> executing 32-bit code? Or was it that P6 was just more inefficient at
> executing 16-bit code?

Well the 486 was much more efficient at running 32-bit code than the
386. The Pentium was better than the 486. And the PPro was better than
the Pentium.

But yes, there was a tiny drop off in performance at 16-bit code when
using the PPro compared to the previous Pentium. That was due to the
fact that there wasn't a segment register cache in the PPro. However,
the next chip in the same family as PPro, the PII, rectified that by
adding that cache back in again.

Yousuf Khan
Anonymous
a b à CPUs
June 6, 2005 5:02:11 PM

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

Jason Gurtz wrote:
> On 6/3/2005 21:08, Yousuf Khan wrote:
>
> > Why do you think 64-bit would require more power draw?
>
> Well, I was thinking that it would represent a "hacked" addition of the
> feature to satisfy PHB types at the last moment since this amd64 thing got
> rushed into the market and there wouldn't really be an optimal
> implementation from Intel until the generation after yonah.

Well, they are making other changes to the architecture in the
meantime, so they might as well add the 64-bit instructions. However,
from what I hear about P-M, it's got power management circuits that
turn off disused parts of the chip. So it's likely that adding the
64-bit instructions would require moving some of these circuits out of
the way too.

Yousuf Khan
Anonymous
a b à CPUs
June 6, 2005 6:32:27 PM

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

On 6/3/2005 21:08, Yousuf Khan wrote:

> Why do you think 64-bit would require more power draw?

Well, I was thinking that it would represent a "hacked" addition of the
feature to satisfy PHB types at the last moment since this amd64 thing got
rushed into the market and there wouldn't really be an optimal
implementation from Intel until the generation after yonah.

~Jason

--
Anonymous
a b à CPUs
June 6, 2005 7:23:14 PM

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

On 6/5/2005 13:25, Yousuf Khan wrote:
> What are you talking about? 32-bit was around for at least ten years
> prior to that, with the 386 in 1985. The P6 architecture was about the
> fourth generation of 32-bit chips in the x86 line

Wasn't the P6 the first 32-bit generation that was much more efficient at
executing 32-bit code? Or was it that P6 was just more inefficient at
executing 16-bit code?

I ask because I think I remember benchmarks at the then fledgling THG
that directly compared PPro 200 with a Pentium 200MMX that showed that
kind of oddity. Of course, I could be totally off base here; it seems so
long ago.

~Jason

--
Anonymous
a b à CPUs
June 6, 2005 8:16:28 PM

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

Ahh, a long standing mystery (to me) finally solved :) 

~Jason

--
June 7, 2005 2:01:03 AM

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

On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:

> Jason Gurtz wrote:
>> Wasn't the P6 the first 32-bit generation that was much more efficient at
>> executing 32-bit code? Or was it that P6 was just more inefficient at
>> executing 16-bit code?
>
> Well the 486 was much more efficient at running 32-bit code than the
> 386. The Pentium was better than the 486. And the PPro was better than
> the Pentium.
>
> But yes, there was a tiny drop off in performance at 16-bit code when
> using the PPro compared to the previous Pentium. That was due to the
> fact that there wasn't a segment register cache in the PPro.

It was *not* in any way "tiny". It was a significant performance hit, so
much so that the P6 was unsuable in Win. To be fair, it was supposed to
be a server chip and 32bit only.

> However, the next chip in the same family as PPro, the PII, rectified that by
> adding that cache back in again.

I thought they renamed the segment registers, rather than cache them, per
se. Felg has the skinny here.

--
Keith
Anonymous
a b à CPUs
June 7, 2005 2:52:50 AM

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

On Mon, 06 Jun 2005 15:23:14 -0400, Jason Gurtz <ask@NOmeSPAM.where>
wrote:

>On 6/5/2005 13:25, Yousuf Khan wrote:
>> What are you talking about? 32-bit was around for at least ten years
>> prior to that, with the 386 in 1985. The P6 architecture was about the
>> fourth generation of 32-bit chips in the x86 line
>
>Wasn't the P6 the first 32-bit generation that was much more efficient at
>executing 32-bit code? Or was it that P6 was just more inefficient at
>executing 16-bit code?

The Pentium Pro was lacking one small feature that hurt performance in
16-bit code by about 10-15%. This feature was added back to the
architecture with the PII.

Note that referring to the Pentium-M and the PentiumPro as being of
the same architecture is really stretching things. While the
Pentium-M might be able to trace it's roots back to the PentiumPro,
the two chips are VERY different in virtually every aspect.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 7, 2005 4:12:00 PM

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

keith wrote:
> On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:
> > But yes, there was a tiny drop off in performance at 16-bit code when
> > using the PPro compared to the previous Pentium. That was due to the
> > fact that there wasn't a segment register cache in the PPro.
>
> It was *not* in any way "tiny". It was a significant performance hit, so
> much so that the P6 was unsuable in Win. To be fair, it was supposed to
> be a server chip and 32bit only.

It was around a 5% drop as I recall. I remember reading it at the time,
and thinking it was much ado about nothing.

> > However, the next chip in the same family as PPro, the PII, rectified that by
> > adding that cache back in again.
>
> I thought they renamed the segment registers, rather than cache them, per
> se. Felg has the skinny here.

If they used register renaming then that's a form of caching the
registers anyways.

Yousuf Khan
Anonymous
a b à CPUs
June 7, 2005 5:32:33 PM

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

On 6/6/2005 22:01, keith wrote:

> much so that the P6 was unsuable in Win.

It was pretty good with NT 4.0

~Jason

--
June 7, 2005 11:51:38 PM

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

On Tue, 07 Jun 2005 13:32:33 -0400, Jason Gurtz wrote:

> On 6/6/2005 22:01, keith wrote:
>
>> much so that the P6 was unsuable in Win.
>
> It was pretty good with NT 4.0

....and NT4 was available when PPro shipped? It really wasn't that great
with NT4. The PII would be a more contemporary comparison. ...and NT4
wasn't a screamer.

--
Keith
June 7, 2005 11:54:13 PM

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

On Tue, 07 Jun 2005 12:12:00 -0700, YKhan wrote:

> keith wrote:
>> On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:
>> > But yes, there was a tiny drop off in performance at 16-bit code when
>> > using the PPro compared to the previous Pentium. That was due to the
>> > fact that there wasn't a segment register cache in the PPro.
>>
>> It was *not* in any way "tiny". It was a significant performance hit, so
>> much so that the P6 was unsuable in Win. To be fair, it was supposed to
>> be a server chip and 32bit only.
>
> It was around a 5% drop as I recall. I remember reading it at the time,
> and thinking it was much ado about nothing.

It was far woese than that. The PPro was slower than the P5. Segment
register reloads were *expensive*, and they're all over Win9x.

>> > However, the next chip in the same family as PPro, the PII, rectified that by
>> > adding that cache back in again.
>>
>> I thought they renamed the segment registers, rather than cache them, per
>> se. Felg has the skinny here.
>
> If they used register renaming then that's a form of caching the
> registers anyways.

A maggot is a form of a fly too.

--
Keith
June 7, 2005 11:59:31 PM

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

On Mon, 06 Jun 2005 22:52:50 -0400, Tony Hill wrote:

> On Mon, 06 Jun 2005 15:23:14 -0400, Jason Gurtz <ask@NOmeSPAM.where>
> wrote:
>
>>On 6/5/2005 13:25, Yousuf Khan wrote:
>>> What are you talking about? 32-bit was around for at least ten years
>>> prior to that, with the 386 in 1985. The P6 architecture was about the
>>> fourth generation of 32-bit chips in the x86 line
>>
>>Wasn't the P6 the first 32-bit generation that was much more efficient at
>>executing 32-bit code? Or was it that P6 was just more inefficient at
>>executing 16-bit code?
>
> The Pentium Pro was lacking one small feature that hurt performance in
> 16-bit code by about 10-15%. This feature was added back to the
> architecture with the PII.

I don't think this is quite accurate. The PPro was not *supposed* to
execute 16bit code, thus the architects didn't see any harm in making
segment register reloads expensive. They *added* the segment register
renaming (cacheing) to ameliorate this problem, in the PII. Anyway, if
you can wake up Felg, he has the real deal. I looked through my email
archives and couldn't find the info.

> Note that referring to the Pentium-M and the PentiumPro as being of the
> same architecture is really stretching things. While the Pentium-M
> might be able to trace it's roots back to the PentiumPro, the two chips
> are VERY different in virtually every aspect.

Gee, I thought all Intel's been doing for a couple of decades is
cranking up the clock! ;-)

--
Keith
Anonymous
a b à CPUs
June 8, 2005 4:27:39 AM

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

On Mon, 06 Jun 2005 22:01:03 -0400, keith <krw@att.bizzzz> wrote:

>On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:
>
>> Jason Gurtz wrote:
>>> Wasn't the P6 the first 32-bit generation that was much more efficient at
>>> executing 32-bit code? Or was it that P6 was just more inefficient at
>>> executing 16-bit code?
>>
>> Well the 486 was much more efficient at running 32-bit code than the
>> 386. The Pentium was better than the 486. And the PPro was better than
>> the Pentium.
>>
>> But yes, there was a tiny drop off in performance at 16-bit code when
>> using the PPro compared to the previous Pentium. That was due to the
>> fact that there wasn't a segment register cache in the PPro.
>
>It was *not* in any way "tiny". It was a significant performance hit, so
>much so that the P6 was unsuable in Win. To be fair, it was supposed to
>be a server chip and 32bit only.

Come now Keith, that's a HUGE exaggeration. The drop in performance
really was TINY, and yes I did use some PPro systems in Win95.
Honestly a PPro 200MHz with 256KB of cache was about 10-15% slower
than a Pentium 200 in most 16-bit Win95 apps, and it was FASTER any
time you started running any 32-bit Win95 apps (of which there were
quite a number when these chips were common) and MUCH faster as soon
as you hit any heavy 32-bit FP code.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 8, 2005 4:27:42 AM

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

On Tue, 07 Jun 2005 19:51:38 -0400, keith <krw@att.bizzzz> wrote:

>On Tue, 07 Jun 2005 13:32:33 -0400, Jason Gurtz wrote:
>
>> On 6/6/2005 22:01, keith wrote:
>>
>>> much so that the P6 was unsuable in Win.
>>
>> It was pretty good with NT 4.0
>
>...and NT4 was available when PPro shipped? It really wasn't that great
>with NT4. The PII would be a more contemporary comparison. ...and NT4
>wasn't a screamer.

The PPro was first shipped late 1995, NT4.0 was first shipped mid 1996
and the PII was first shipped mid 1997. So in a sense the PPro and NT
4.0 were out in the same basic timeframe.

That being said though, NT 4.0 wasn't really useable until Service
Pack 4 was released, and that didn't happen until sometime in '99.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 8, 2005 7:00:20 AM

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

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.06.07.23.59.30.72615@att.bizzzz...
>
> Anyway, if
> you can wake up Felg, he has the real deal. I looked through my
email
> archives and couldn't find the info.

I _had_ the real deal. I did some housecleaning and tossed the really
old stuff, like the above. No longer interested in the PPro. Sorry.
Anonymous
a b à CPUs
June 8, 2005 5:01:39 PM

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

keith <krw@att.bizzzz> wrote:
> On Mon, 06 Jun 2005 12:57:07 -0700, YKhan wrote:

> > Jason Gurtz wrote:
> >> Wasn't the P6 the first 32-bit generation that was much more efficient at
> >> executing 32-bit code? Or was it that P6 was just more inefficient at
> >> executing 16-bit code?
> >
> > Well the 486 was much more efficient at running 32-bit code than the
> > 386. The Pentium was better than the 486. And the PPro was better than
> > the Pentium.
> >
> > But yes, there was a tiny drop off in performance at 16-bit code when
> > using the PPro compared to the previous Pentium. That was due to the
> > fact that there wasn't a segment register cache in the PPro.

> It was *not* in any way "tiny". It was a significant performance hit, so
> much so that the P6 was unsuable in Win. To be fair, it was supposed to
> be a server chip and 32bit only.

It wasn't that bad.

Intel was able to crank out 150 MHz PPro's on the same process as 120
Pentium's (0.6um BiCMOS), and If you compared them that way, the 150 MHz
PPro's were ever so slightly faster on Win 3.x. If you compared them on
equal MHz situation, it was about 15~20% hit.

For reference, take a look at Linley Gwennap's article in the
Microprocessor Reports. July 31, 1995 (Volume 9, Number 10)
"P6 Underperforms on 16-bit code"

Comparing a P6-150 (0.6um BiCMOS) against a P5-133 (0.35um BiCMOS), a
figure was drawn, and I'm roughly transcribing the relative performance
numbers from the figure. (performance relative to P5-100)

P5-133 P6-150
Win 3.1 (Sysmark) ~1.2 ~1.05
Win95 (per Intel) ~1.1 ~1.4
WinNT (Sysmark NT) ~1.2 ~1.75
Unix (SPECint92) ~1.3 ~2.1




--
davewang202(at)yahoo(dot)com
Anonymous
a b à CPUs
June 8, 2005 5:13:53 PM

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

keith <krw@att.bizzzz> wrote:
> On Mon, 06 Jun 2005 22:52:50 -0400, Tony Hill wrote:

> > The Pentium Pro was lacking one small feature that hurt performance in
> > 16-bit code by about 10-15%. This feature was added back to the
> > architecture with the PII.

> I don't think this is quite accurate. The PPro was not *supposed* to
> execute 16bit code, thus the architects didn't see any harm in making
> segment register reloads expensive. They *added* the segment register
> renaming (cacheing) to ameliorate this problem, in the PII. Anyway, if
> you can wake up Felg, he has the real deal. I looked through my email
> archives and couldn't find the info.

You're off base in this case.

The PPro was supposed to execute everything, there wasn't a
conscious effort to optimize "32 bit code" and leave out "16 bit". It
was just that the architects didn't realize how important some of
these things such as partial register usage were. The architects
came from a non-x86 background, and they were thinking about high
performance. There were talks about the segment registers during
the architecture phase of the processor, but the ball was dropped,
and there were some miscommunication about how important segment
register rename was, and partial register usage too. I remember
Andy Glew talking quite a bit about the partial register usage,
and he took the blame for that as well IIRC.

The basic idea of the PPro was to make the common case fast, and
the not-so-common case, not-so-fast. Unfortuantely, some of the
cases thought to be not-so-common turned out to be more common
than believed. This whole thing about "16 bit software" is just
a cover all term to mean "legacy software that contained a bunch
of weird hand coded stuff that the architects of P6 didn't think
would be common."

--
davewang202(at)yahoo(dot)com
Anonymous
a b à CPUs
June 9, 2005 4:07:54 PM

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

keith <krw@att.bizzzz> wrote:
> On Tue, 07 Jun 2005 13:32:33 -0400, Jason Gurtz wrote:
> > It was pretty good with NT 4.0
>
> ...and NT4 was available when PPro shipped? It really wasn't that great
> with NT4. The PII would be a more contemporary comparison. ...and NT4
> wasn't a screamer.

As long as you had enough memory, NT4 ran pretty well on machines as slow as
a Pentium(classic) 75mhz ... for native Win32 applications, generally better
than Win 95.

The key thing was that you really needed a good chunk of memory to run it
comfortably. Of course, a good chunk of memory by today's standards is
tiny, but back in mid-96 when NT 4.0 came out...

--
Nate Edel http://www.cubiclehermit.com/

"This is not a humorous signature."
June 10, 2005 6:30:11 AM

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

On Thu, 09 Jun 2005 12:07:54 -0700, archmage@sfchat.org (Nate Edel)
wrote:

>keith <krw@att.bizzzz> wrote:
>> On Tue, 07 Jun 2005 13:32:33 -0400, Jason Gurtz wrote:
>> > It was pretty good with NT 4.0
>>
>> ...and NT4 was available when PPro shipped? It really wasn't that great
>> with NT4. The PII would be a more contemporary comparison. ...and NT4
>> wasn't a screamer.
>
>As long as you had enough memory, NT4 ran pretty well on machines as slow as
>a Pentium(classic) 75mhz ... for native Win32 applications, generally better
>than Win 95.
>
>The key thing was that you really needed a good chunk of memory to run it
>comfortably. Of course, a good chunk of memory by today's standards is
>tiny, but back in mid-96 when NT 4.0 came out...
Heck, even a 486 (actually, AMD 586-133) with 32 MB RAM was good
enough to run NT4 until it came to SP4 (or was it even SP3?) that
slowed things down quite noticeably. As for P75 with 48MB RAM running
NT4 - that's exactly the config Chase provided to me in late 1998 to
do some consulting work for them. Well, they paid by an hour, and I
always could go get a cup of coffee while that clunker was crunching
the data at 100% CPU load...
!