details about dual-core Yonah emerge

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+next+notebook+chip/2100-1006_3-5729925.html

Yousuf Khan
30 answers Last reply
More about details dual core yonah emerge
  1. 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.
  2. 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.
  3. 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

    --
  4. 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
  5. 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
  6. 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
  7. 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.
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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

    --
  15. 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

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

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

    ~Jason

    --
  17. 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
  18. 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
  19. 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
  20. 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

    --
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

    "keith" <krw@att.bizzzz> wrote in message
    news:pan.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.
  27. 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
  28. 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
  29. 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."
  30. 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...
Ask a new question

Read More

CPUs Dual Core