Intel engineer discusses their dual-core design

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

In article <de7q2q$i0m$1@osl016lin.hda.hydro.com>,
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
>Robert Redelmeier wrote:
>
>> For example, I have no trouble lying to a saleman saying "I'm busy"
>> rather than telling him "Your product is grossly overpriced,
>> I'm insulted you think I'm so stupid as to fall for it, and I
>> find you obnoxious." The latter may be entirely true, but it is
>> valuable information (feedback) the saleman has not earned.
>
>🙂

Hmm. I have no difficulty in telling him the former, though I would
leave out the remark about his obnoxiousness as unprofessional.

I have several times told salesmen and even technical staff that
their product would be cancelled, on the grounds that it would fail
in testing, including once when it had a shipment dated of under
6 months off. I told them I had seen it attempted N times before,
it had failed every time for fundamental reasons, and I didn't care
how senior the executive was who had told them it would succeed
THIS time - he didn't know what he was rabbiting on about and I did.
I may have used those words 🙂

That particular product was virtual shared memory, as a platform
to run arbitrary SMP programs on a distributed memory system.


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

On Thu, 18 Aug 2005 09:59:19 -0700, icerq4a wrote:

>
> keith skrev:
>
>> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>
>> > http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>
>> I simply found it an admission of how far (and for how long) their
>> technological head is (and has been) up their corporate ass. Nine months
>> in development isn't that big of a deal, given that the "cores" are
>> already there. Years? Please! They don't simulate/verify in
>> multi-processor environments? *Amazing*!
>
> The only amazing thing here is that you don't seem to understand the
> article and appear to know nothing about microprocessor development.

Uh, right. Since that's (microprocessor development) what I do for a
living, I suggest that *you* read the article again. This time you
might try reading for comprehension. Intel blew it big time, as did you.

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

On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:

> keith wrote:
>> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>
>>
>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>
>>
>> I simply found it an admission of how far (and for how long) their
>> technological head is (and has been) up their corporate ass. Nine months
>> in development isn't that big of a deal, given that the "cores" are
>> already there. Years? Please! They don't simulate/verify in
>> multi-processor environments? *Amazing*!
>>
> If these cores are the desktop versions rather than Xeon, they were not
> planned to be used in SMP, much less in dual core. I'd be interested to
> get your spin on why they *would* test the desktop chip SMP.

Spin? Like to load them words, eh? One reason to do SMP testing is that
it's "easy" to test cache coherence with two processors. Two processors
can bang the caches pretty hard against each other.

Do you really think Intel has no SMP verification capabilities? Do they
not "borrow" tools from one organization to another? There's more here
than meets the eye. Someone dropped the ball, big time!

> Here's a more interesting question: Intel built the D/C chips on P4
> rather than P-M, presumably so they could offer the ht model at a huge
> premium. Given the low power and far better performance of the P-M in
> terms of work/watt and work/clock, why not a dual core Pentium-M? Then
> when the better P4 D/C chip is ready they could offer that?

Absolutely. ...which makes the SMP verification issue even more
strange.

> Just curious as to the logic for the decision if anyone has any insight.

Search me. I've given up trying to explain Intel's moves; too bizare.

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

keith wrote:
> On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>
>
>>keith wrote:
>>
>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>
>>>
>>>
>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>
>>>
>>>I simply found it an admission of how far (and for how long) their
>>>technological head is (and has been) up their corporate ass. Nine months
>>>in development isn't that big of a deal, given that the "cores" are
>>>already there. Years? Please! They don't simulate/verify in
>>>multi-processor environments? *Amazing*!
>>>
>>
>>If these cores are the desktop versions rather than Xeon, they were not
>>planned to be used in SMP, much less in dual core. I'd be interested to
>>get your spin on why they *would* test the desktop chip SMP.
>
>
> Spin? Like to load them words, eh? One reason to do SMP testing is that
> it's "easy" to test cache coherence with two processors. Two processors
> can bang the caches pretty hard against each other.
>
> Do you really think Intel has no SMP verification capabilities? Do they
> not "borrow" tools from one organization to another? There's more here
> than meets the eye. Someone dropped the ball, big time!

I'm a bit confused. You are talking "verification", but the article
talks about "testing tools and processes".

I thought "verification" meant determining the correctness of the
design, but "testing" often refers to the part of the manufacturing
process that tries to determine whether a newly manufactured chip
conforms to the design.

In those senses, verification of an SMP design should include simulation
of multiple processors. Testing should apply to each chip separately,
because if you put two or more chips together and the result fails, you
only know that one of a set of chips is bad, not which one it is.

Are you using the words that way? If not, could you define
"verification" and "testing"?

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

keith <krw@att.bizzzz> wrote:

> On Thu, 18 Aug 2005 09:59:19 -0700, icerq4a wrote:
>
> > keith skrev:
> >
> >> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
> >>
> >> > http://www.macworld.com/news/2005/08/17/dualcore/index.php
> >>
> >> I simply found it an admission of how far (and for how long) their
> >> technological head is (and has been) up their corporate ass. Nine months
> >> in development isn't that big of a deal, given that the "cores" are
> >> already there. Years? Please! They don't simulate/verify in
> >> multi-processor environments? *Amazing*!
> >
> > The only amazing thing here is that you don't seem to understand the
> > article and appear to know nothing about microprocessor development.
>
> Uh, right. Since that's (microprocessor development) what I do for a
> living, I suggest that *you* read the article again. This time you
> might try reading for comprehension. Intel blew it big time, as did you.

Mudslinging apart, the admission is not new. It is a long time ago that
Intel top brass talked about a sudden 90 degree right turn.

What is new, is that we now know that Intel wanted to be able to match
cores with the same performance per watt in a package. Without that
ability, you have to disable the core that runs, but not well enough. Or
waste a good core. We now know that that package is cheaper for Intel
than disabling a core.

--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

On Sun, 21 Aug 2005 17:19:16 +0000, Patricia Shanahan wrote:

> keith wrote:
>> On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>>
>>
>>>keith wrote:
>>>
>>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>>
>>>>
>>>>
>>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>>
>>>>
>>>>I simply found it an admission of how far (and for how long) their
>>>>technological head is (and has been) up their corporate ass. Nine months
>>>>in development isn't that big of a deal, given that the "cores" are
>>>>already there. Years? Please! They don't simulate/verify in
>>>>multi-processor environments? *Amazing*!
>>>>
>>>
>>>If these cores are the desktop versions rather than Xeon, they were not
>>>planned to be used in SMP, much less in dual core. I'd be interested to
>>>get your spin on why they *would* test the desktop chip SMP.
>>
>>
>> Spin? Like to load them words, eh? One reason to do SMP testing is that
>> it's "easy" to test cache coherence with two processors. Two processors
>> can bang the caches pretty hard against each other.
>>
>> Do you really think Intel has no SMP verification capabilities? Do they
>> not "borrow" tools from one organization to another? There's more here
>> than meets the eye. Someone dropped the ball, big time!
>
> I'm a bit confused. You are talking "verification", but the article
> talks about "testing tools and processes".

I don't think so. "Testing" is a function of ATE widgets. There
comparatively little development needed to "test" a dual-core
processor. Verification was what the article was referring to.

> I thought "verification" meant determining the correctness of the
> design, but "testing" often refers to the part of the manufacturing
> process that tries to determine whether a newly manufactured chip
> conforms to the design.

Fine, if you want to skin the onion that thin. Why should it take that
much work to "test" a dual core processor?

> In those senses, verification of an SMP design should include simulation
> of multiple processors. Testing should apply to each chip separately,
> because if you put two or more chips together and the result fails, you
> only know that one of a set of chips is bad, not which one it is.

One doesn't "test" multiple processors. One tests products. If one has
it together, the "tests" fall out of the verification suites (more or less).

> Are you using the words that way? If not, could you define
> "verification" and "testing"?

I won't argue much with your definitions, just that they're normally
confused. "Verification" includes both simulation and engineering "test"
(we have both "verification" and "hardware verification" groups).
Manufacturing test is something else. Once the design is shown to work,
making sure the one shipped to the customer works is induction. ;-)

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

"Rob Stow" <rob.stow@shaw.ca> wrote in message
news:mAaNe.248366$5V4.83816@pd7tw3no...
> icerq4a@spray.se wrote:
> > keith skrev:
> >
> >
> >>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
> >>
> >>
> >>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
> >>
> >>I simply found it an admission of how far (and for how long) their
> >>technological head is (and has been) up their corporate ass. Nine
months
> >>in development isn't that big of a deal, given that the "cores" are
> >>already there. Years? Please! They don't simulate/verify in
> >>multi-processor environments? *Amazing*!
> >
> >
> > The only amazing thing here is that you don't seem to understand the
> > article and appear to know nothing about microprocessor development.
> >
>
> Better put on your flame retardant suit.
>
> You, as a newbie to this group with no credentials established
> are telling Keith, with well established creds, that he knows
> nothing about microprocessor development ?

Go look at the variable bit cpu thread, where Keith is trolling as a
mindless donut about "base".

In my book he is a troll.

Bye,
Skybuck

P.S.: Revenge is sweet.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:debiim$dk$1@news4.zwoll1.ov.home.nl...
>
>

<Blahter removed>

> In my book he is a troll.

Oooh! A little net cop! How cute!

> Bye,
> Skybuck
>
> P.S.: Revenge is sweet.

I'll go away now, cross posting slime.

--

... Hank

http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

keith wrote:
> On Sun, 21 Aug 2005 17:19:16 +0000, Patricia Shanahan wrote:
>
>
>>keith wrote:
>>
>>>On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>>>
>>>
>>>
>>>>keith wrote:
>>>>
>>>>
>>>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>>>
>>>>>
>>>>>I simply found it an admission of how far (and for how long) their
>>>>>technological head is (and has been) up their corporate ass. Nine months
>>>>>in development isn't that big of a deal, given that the "cores" are
>>>>>already there. Years? Please! They don't simulate/verify in
>>>>>multi-processor environments? *Amazing*!
>>>>>
>>>>
>>>>If these cores are the desktop versions rather than Xeon, they were not
>>>>planned to be used in SMP, much less in dual core. I'd be interested to
>>>>get your spin on why they *would* test the desktop chip SMP.
>>>
>>>
>>>Spin? Like to load them words, eh? One reason to do SMP testing is that
>>>it's "easy" to test cache coherence with two processors. Two processors
>>>can bang the caches pretty hard against each other.
>>>
>>>Do you really think Intel has no SMP verification capabilities? Do they
>>>not "borrow" tools from one organization to another? There's more here
>>>than meets the eye. Someone dropped the ball, big time!
>>
>>I'm a bit confused. You are talking "verification", but the article
>>talks about "testing tools and processes".
>
>
> I don't think so. "Testing" is a function of ATE widgets. There
> comparatively little development needed to "test" a dual-core
> processor. Verification was what the article was referring to.
>
>
>>I thought "verification" meant determining the correctness of the
>>design, but "testing" often refers to the part of the manufacturing
>>process that tries to determine whether a newly manufactured chip
>>conforms to the design.
>
>
> Fine, if you want to skin the onion that thin. Why should it take that
> much work to "test" a dual core processor?
>
>
>>In those senses, verification of an SMP design should include simulation
>>of multiple processors. Testing should apply to each chip separately,
>>because if you put two or more chips together and the result fails, you
>>only know that one of a set of chips is bad, not which one it is.
>
>
> One doesn't "test" multiple processors. One tests products. If one has
> it together, the "tests" fall out of the verification suites (more or less).
>
>
>>Are you using the words that way? If not, could you define
>>"verification" and "testing"?
>
>
> I won't argue much with your definitions, just that they're normally
> confused. "Verification" includes both simulation and engineering "test"
> (we have both "verification" and "hardware verification" groups).
> Manufacturing test is something else. Once the design is shown to work,
> making sure the one shipped to the customer works is induction. ;-)
>

I just thought of an interesting angle. Intel seems to have two
organizations, one for desktops and one for servers. Could all the
knowledge and testcases for SMP>2 reside in the server group, and the
chip being discussed reside in the desktop group? Might they have
trouble sharing?

Ore was it just a schedule and resource thang?

Just some idle speculation

--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

On Mon, 22 Aug 2005 06:02:12 +0200, Skybuck Flying wrote:

>
> "Rob Stow" <rob.stow@shaw.ca> wrote in message
> news:mAaNe.248366$5V4.83816@pd7tw3no...
>> icerq4a@spray.se wrote:
>> > keith skrev:
>> >
>> >
>> >>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>> >>
>> >>
>> >>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>> >>
>> >>I simply found it an admission of how far (and for how long) their
>> >>technological head is (and has been) up their corporate ass. Nine
> months
>> >>in development isn't that big of a deal, given that the "cores" are
>> >>already there. Years? Please! They don't simulate/verify in
>> >>multi-processor environments? *Amazing*!
>> >
>> >
>> > The only amazing thing here is that you don't seem to understand the
>> > article and appear to know nothing about microprocessor development.
>> >
>>
>> Better put on your flame retardant suit.
>>
>> You, as a newbie to this group with no credentials established
>> are telling Keith, with well established creds, that he knows
>> nothing about microprocessor development ?
>
> Go look at the variable bit cpu thread, where Keith is trolling as a
> mindless donut about "base".

Really? You propose a bit of marker per bit of data and you complain
about people suggesting that base-2 may not be ideal? You then go on to
swear, bitch, and moan (the latter only in your more lucid moments), and
then complain that peoplae call _you_ a waste? Note folks that I'm not
alone.

> In my book he is a troll.

I suggest a google on sky, if you want a definition of a troll.

> Bye,
> Skybuck
>
> P.S.: Revenge is sweet.


Revenge? Please!

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

On Sun, 21 Aug 2005 19:07:28 +0200, Niels Jørgen Kruse wrote:

> keith <krw@att.bizzzz> wrote:
>
>> On Thu, 18 Aug 2005 09:59:19 -0700, icerq4a wrote:
>>
>> > keith skrev:
>> >
>> >> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>> >>
>> >> > http://www.macworld.com/news/2005/08/17/dualcore/index.php
>> >>
>> >> I simply found it an admission of how far (and for how long) their
>> >> technological head is (and has been) up their corporate ass. Nine months
>> >> in development isn't that big of a deal, given that the "cores" are
>> >> already there. Years? Please! They don't simulate/verify in
>> >> multi-processor environments? *Amazing*!
>> >
>> > The only amazing thing here is that you don't seem to understand the
>> > article and appear to know nothing about microprocessor development.
>>
>> Uh, right. Since that's (microprocessor development) what I do for a
>> living, I suggest that *you* read the article again. This time you
>> might try reading for comprehension. Intel blew it big time, as did you.
>
> Mudslinging apart, the admission is not new. It is a long time ago that
> Intel top brass talked about a sudden 90 degree right turn.

After the Itanic hits the iceberg the captain orders a 90 degree turn?
....good plan!

> What is new, is that we now know that Intel wanted to be able to match
> cores with the same performance per watt in a package. Without that
> ability, you have to disable the core that runs, but not well enough. Or
> waste a good core. We now know that that package is cheaper for Intel
> than disabling a core.

Huh? I don't follow that paragraph at all. One wants to run *both*
cores. Otherwise what's the point?

Intel's stacking two cores in an MCM and calling it a "dual core" tells
all. They were caught with their pants down, even after *knowing* what
the score was for a couple of years.

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

On Mon, 22 Aug 2005 10:44:25 -0500, Del Cecchi wrote:

> keith wrote:
>> On Sun, 21 Aug 2005 17:19:16 +0000, Patricia Shanahan wrote:
>>
>>
>>>keith wrote:
>>>
>>>>On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>>>>
>>>>
>>>>
>>>>>keith wrote:
>>>>>
>>>>>
>>>>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>>>>
>>>>>>
>>>>>>I simply found it an admission of how far (and for how long) their
>>>>>>technological head is (and has been) up their corporate ass. Nine months
>>>>>>in development isn't that big of a deal, given that the "cores" are
>>>>>>already there. Years? Please! They don't simulate/verify in
>>>>>>multi-processor environments? *Amazing*!
>>>>>>
>>>>>
>>>>>If these cores are the desktop versions rather than Xeon, they were not
>>>>>planned to be used in SMP, much less in dual core. I'd be interested to
>>>>>get your spin on why they *would* test the desktop chip SMP.
>>>>
>>>>
>>>>Spin? Like to load them words, eh? One reason to do SMP testing is that
>>>>it's "easy" to test cache coherence with two processors. Two processors
>>>>can bang the caches pretty hard against each other.
>>>>
>>>>Do you really think Intel has no SMP verification capabilities? Do they
>>>>not "borrow" tools from one organization to another? There's more here
>>>>than meets the eye. Someone dropped the ball, big time!
>>>
>>>I'm a bit confused. You are talking "verification", but the article
>>>talks about "testing tools and processes".
>>
>>
>> I don't think so. "Testing" is a function of ATE widgets. There
>> comparatively little development needed to "test" a dual-core
>> processor. Verification was what the article was referring to.
>>
>>
>>>I thought "verification" meant determining the correctness of the
>>>design, but "testing" often refers to the part of the manufacturing
>>>process that tries to determine whether a newly manufactured chip
>>>conforms to the design.
>>
>>
>> Fine, if you want to skin the onion that thin. Why should it take that
>> much work to "test" a dual core processor?
>>
>>
>>>In those senses, verification of an SMP design should include simulation
>>>of multiple processors. Testing should apply to each chip separately,
>>>because if you put two or more chips together and the result fails, you
>>>only know that one of a set of chips is bad, not which one it is.
>>
>>
>> One doesn't "test" multiple processors. One tests products. If one has
>> it together, the "tests" fall out of the verification suites (more or less).
>>
>>
>>>Are you using the words that way? If not, could you define
>>>"verification" and "testing"?
>>
>>
>> I won't argue much with your definitions, just that they're normally
>> confused. "Verification" includes both simulation and engineering "test"
>> (we have both "verification" and "hardware verification" groups).
>> Manufacturing test is something else. Once the design is shown to work,
>> making sure the one shipped to the customer works is induction. ;-)
>>
>
> I just thought of an interesting angle. Intel seems to have two
> organizations, one for desktops and one for servers. Could all the
> knowledge and testcases for SMP>2 reside in the server group, and the
> chip being discussed reside in the desktop group? Might they have
> trouble sharing?

NIH on sterroids? I don't buy it. The first Xeons were Pentiums with the
SMP-limiting fuses unblown. The Pentium design was SMP capable, but the
desktop versions had the function disabled.

That's a *lot* of NIH you're proposing!

> Ore was it just a schedule and resource thang?

I don't buy that either. I smell an excuse for some really bad management
decisions. ...blame the techies!

> Just some idle speculation

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

Yeah sure, my opinion of Sony has gone down too. But even back in its
heyday I was never one to go around buying Sony when there were
equivalent but cheaper products from JVC, Panasonic and others to
choose from. In fact, I don't think I have or ever had a Sony of
anything -- which is probably kind of telling of my personality, I
guess.

Regarding Intel's brand degradation, it's a little different. It's
competing against a brand that doesn't advertise (at least to the same
level). I think AMD is doing the right thing here, which they weren't
before. Nowadays they're trying to appeal to the IT professional, and
the high-performance gaming enthusiast, and building its reputation
top-down. In the past it was trying to sell everything for cheaper than
Intel, and all they were getting were the cheapskates who don't really
care about brandnames anyways.

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

keith <krw@att.bizzzz> wrote:

> Intel's stacking two cores in an MCM and calling it a "dual core" tells
> all. They were caught with their pants down, even after *knowing* what
> the score was for a couple of years.

No, the package wasn't ready so they had to put both on the same die.

Why don't you read the article?

--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

On Fri, 19 Aug 2005 18:56:44 +0000, Rob Stow wrote:

>> I think AMD has finally managed to tarnish "Intel Inside."
>
> Finally ? Where have you been hiding for the last 4 or 5 years ?

Intel Inside was more about perception than reality. The reality might
have been tarnished for a while, but I'm now noticing too for the first
time that the general perception (outside geekier circles) is finally
taking some damage.

But by the time it really starts to bite, Intel will probably have some
nice Pentium M based stuff to offer and past mistakes will soon be
forgotten.

The main difference I see in perceptions of both AMD and Intel is that the
market will ignore or forget Intels mistakes while punishing AMD for
theirs and won't forget them quickly.

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

"keith" <krw@att.bizzzz> wrote in message
news😛an.2005.08.23.02.04.28.134199@att.bizzzz...

> Intel's stacking two cores in an MCM and calling it a "dual core" tells
> all. They were caught with their pants down, even after *knowing* what
> the score was for a couple of years.

First of all, they didn't do that. Second of all, a "dual core" is two
processors in one physical package.

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

David Schwartz wrote:

....

a "dual core" is two
> processors in one physical package.

Not by any current definition that I'm aware of: it is, rather, two
cores on a single chip.

Do you call POWER an '8-core' processor because that's how many cores
its high-end systems have in one physical package?

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

Dean Kent wrote:
> What hasn't changed much is the overall market share for x86, and that does
> keep Intel firmly in the driver's seat, so the crown is still theirs to
> lose. While there are always those who will pull for the underdog, the
> majority still give the current 'champion' the benefit of the doubt in any
> contest, making Intel's job a bit easier than AMD's even with a bit of an
> imbalance in price/performance. AMD must keep the imbalance large for some
> time before they are considered legitimate and finally tip the scales
> permanently - but relying on a single market segment is somewhat dangerous,
> and that has always been AMD's Achilles heel.

Maybe it's just a matter of time while AMD keeps up the pressure, as
you said; afterall, AMD has had the technological advantage over Intel
for over two years now, which is a lot of time pressure. But it also
looks like the anti-trust lawsuit has now hamstrung Intel tangibly. It
can't apply the same pressures on OEMs & retailers that forced them to
"give over" the benefit of the doubt. Throughout most cities, it's
looking like there's been an increase in the number of AMD PCs,
especially laptops, something that was rarely ever seen prior to the
lawsuit.

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

On Tue, 23 Aug 2005 13:17:59 +1200, "AD." <me@privacy.net> wrote:

>On Fri, 19 Aug 2005 18:56:44 +0000, Rob Stow wrote:
>
>>> I think AMD has finally managed to tarnish "Intel Inside."
>>
>> Finally ? Where have you been hiding for the last 4 or 5 years ?
>
>Intel Inside was more about perception than reality. The reality might
>have been tarnished for a while, but I'm now noticing too for the first
>time that the general perception (outside geekier circles) is finally
>taking some damage.
>
>But by the time it really starts to bite, Intel will probably have some
>nice Pentium M based stuff to offer and past mistakes will soon be
>forgotten.

"Probably"?... maybe?🙂

>The main difference I see in perceptions of both AMD and Intel is that the
>market will ignore or forget Intels mistakes while punishing AMD for
>theirs and won't forget them quickly.

Why would that be?... because Intel is bigger? I don't see that as an
advantage as far as public popularity goes. Or is it because AMD is seen
as an intruder/pretender/copyist? If that, it is something which could
easily be repaired by exposing AMD's true history of real innovation in the
processor industry dating back to the early 80s.

Intel's mistakes have all resulted from allowing marketing depts the power
to guide product technical direction - I don't see that changing much and
in fact they're girding up to do it again; we'll see if AMD suffers from
the same hubris but so far it still looks pretty good.

--
Rgds, George Macdonald
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

"keith" <krw@att.bizzzz> wrote in message
news😛an.2005.08.23.01.59.25.311204@att.bizzzz...
> On Mon, 22 Aug 2005 06:02:12 +0200, Skybuck Flying wrote:
>
> >
> > "Rob Stow" <rob.stow@shaw.ca> wrote in message
> > news:mAaNe.248366$5V4.83816@pd7tw3no...
> >> icerq4a@spray.se wrote:
> >> > keith skrev:
> >> >
> >> >
> >> >>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
> >> >>
> >> >>
> >> >>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
> >> >>
> >> >>I simply found it an admission of how far (and for how long) their
> >> >>technological head is (and has been) up their corporate ass. Nine
> > months
> >> >>in development isn't that big of a deal, given that the "cores" are
> >> >>already there. Years? Please! They don't simulate/verify in
> >> >>multi-processor environments? *Amazing*!
> >> >
> >> >
> >> > The only amazing thing here is that you don't seem to understand the
> >> > article and appear to know nothing about microprocessor development.
> >> >
> >>
> >> Better put on your flame retardant suit.
> >>
> >> You, as a newbie to this group with no credentials established
> >> are telling Keith, with well established creds, that he knows
> >> nothing about microprocessor development ?
> >
> > Go look at the variable bit cpu thread, where Keith is trolling as a
> > mindless donut about "base".
>
> Really? You propose a bit of marker per bit of data and you complain
> about people suggesting that base-2 may not be ideal? You then go on to
> swear, bitch, and moan (the latter only in your more lucid moments), and
> then complain that peoplae call _you_ a waste? Note folks that I'm not
> alone.

You still haven't explained why base 2 would not be ideal !

As long as you don't explain it you remain a troll.

Plain and simple.

>
> > In my book he is a troll.
>
> I suggest a google on sky, if you want a definition of a troll.
>
> > Bye,
> > Skybuck
> >
> > P.S.: Revenge is sweet.
>
>
> Revenge? Please!
>
> --
> Keith
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

Dean Kent wrote:
> "YKhan" <yjkhan@gmail.com> wrote in message
> news:1124891033.268120.244040@g14g2000cwa.googlegroups.com...
> Throughout most cities, it's
> > looking like there's been an increase in the number of AMD PCs,
> > especially laptops, something that was rarely ever seen prior to the
> > lawsuit.
>
> Got a link or reference for that?

Well obviously how many AMD based systems are showing up in local
stores is entirely anecdotal, being reported by individuals dropping by
their local Best Buys, Circuit Cities, Future Shops, whatnot. People
are seeing more laptop systems showing up on display with AMD
processors than they used to. It's not hard picking out an increase in
AMD laptops; whereas previously there might have been none, but now
there might be some -- easy to notice.

But the AMD boss also announced that they recently had 60 design wins
for the Turion. So one would assume that those design wins would be
showing up for sale too.

X-bit labs - Hardware news - AMD Turion 64 Is Gaining Market Acceptance
- Company.
http://www.xbitlabs.com/news/mobile/display/20050715215841.html

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

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:05cng1hesjt3vkbsudrk9pnj0app5pt115@4ax.com...
> On Tue, 23 Aug 2005 13:17:59 +1200, "AD." <me@privacy.net> wrote:
>
> >On Fri, 19 Aug 2005 18:56:44 +0000, Rob Stow wrote:
> >
>
> >The main difference I see in perceptions of both AMD and Intel is that
the
> >market will ignore or forget Intels mistakes while punishing AMD for
> >theirs and won't forget them quickly.
>

The main difference between today and the past is that AMD has a viable
*commercial* product, though the related consumer part is still treading
water like previous AMD products in that space. Opteron has provided AMD
with both profits and perception, and that has been Intel's (and IBM's)
forte in the past. Where Intel has in the past been able to quickly
overcome whatever advantage AMD might have eked out, today they are still
waffling between focusing on IPF and x86 hoping that IPF will provide them
with the means to commoditize the low-end server space (like they did with
the low-end desktop space 10 years ago).

What hasn't changed much is the overall market share for x86, and that does
keep Intel firmly in the driver's seat, so the crown is still theirs to
lose. While there are always those who will pull for the underdog, the
majority still give the current 'champion' the benefit of the doubt in any
contest, making Intel's job a bit easier than AMD's even with a bit of an
imbalance in price/performance. AMD must keep the imbalance large for some
time before they are considered legitimate and finally tip the scales
permanently - but relying on a single market segment is somewhat dangerous,
and that has always been AMD's Achilles heel.

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

"YKhan" <yjkhan@gmail.com> wrote in message
news:1124891033.268120.244040@g14g2000cwa.googlegroups.com...
Throughout most cities, it's
> looking like there's been an increase in the number of AMD PCs,
> especially laptops, something that was rarely ever seen prior to the
> lawsuit.

Got a link or reference for that?

Regards,
Dean

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

Bill Todd wrote:
> David Schwartz wrote:
>
> ...
>
> a "dual core" is two
> > processors in one physical package.
>
> Not by any current definition that I'm aware of: it is, rather, two
> cores on a single chip.
>
> Do you call POWER an '8-core' processor because that's how many cores
> its high-end systems have in one physical package?
>
> - bill

You might also consider an argument of ARM 32-bit Standard Model VS
16-bit THUMB mode VS an entirely different VLIW with a 16-bit/5-bit
architecture as a potential performance differance.

Why is Intel so secretive about it's research of using registers as
stacks outside of Pentium's microcode engine? ( access more data thru
stacks with a similar ( or less!) amount of chip masking and a more
efficient fabrication ( I have seen very few stack architecture
refrences for Intel, for example the IPX multi micro puter engine ,
http:A//www.intel.com/design/network/products/npfamily/ixp2800.htm&ei=fR4NQ7OrCIfK-QG8_LHGCQ
, ))

Although, Mr. Moore's 25x model is an asychronous parallel processor,
VLIW SMP MPP sychronization is unspecified.

URL:
http://groups.google.com/group/comp.lang.java.machine/msg/b400d03ddc0f5a4f?hl=en

If they would have used sixteen 16-bit/5-bit instead of sixteen
32-bit/16-bit maybe Intel would have won. Thank you IBM for Nirvana.

---

President Clinton is a jerk
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)

anonymous wrote:
> Bill Todd wrote:
> > David Schwartz wrote:
> >
> > ...
> >
> > a "dual core" is two
> > > processors in one physical package.
> >
> > Not by any current definition that I'm aware of: it is, rather, two
> > cores on a single chip.
> >
> > Do you call POWER an '8-core' processor because that's how many cores
> > its high-end systems have in one physical package?
> >
> > - bill
>
> You might also consider an argument of ARM 32-bit Standard Model VS
> 16-bit THUMB mode VS an entirely different VLIW with a 16-bit/5-bit
> architecture as a potential performance differance.
>
> Why is Intel so secretive about it's research of using registers as
> stacks outside of Pentium's microcode engine? ( access more data thru
> stacks with a similar ( or less!) amount of chip masking and a more
> efficient fabrication ( I have seen very few stack architecture
> refrences for Intel, for example the IPX multi micro puter engine ,
> http:A//www.intel.com/design/network/products/npfamily/ixp2800.htm&ei=fR4NQ7OrCIfK-QG8_LHGCQ
> , ))
>
> Although, Mr. Moore's 25x model is an asychronous parallel processor,
> VLIW SMP MPP sychronization is unspecified.
>
> URL:
> http://groups.google.com/group/comp.lang.java.machine/msg/b400d03ddc0f5a4f?hl=en
>
> If they would have used sixteen 16-bit/5-bit instead of sixteen
> 32-bit/16-bit maybe Intel would have won. Thank you IBM for Nirvana.
>
> ---
>
> President Clinton is a jerk


www.intel.com/technology/itj/2002/volume06issue03/art01_nextgenixp/vol6iss3_art01.pdf

The type of CAM mentioned in this article is NOT the same as my usage
of the term CAM. In my usage CAM is automatically executed as a
machine intruction , re-mapping back from 5-bit fedback into 16-like,
similar to Inmos Transputer type F instruction except my usage of CAM
permits 15 such mappings.

EITHER a sixteen ( actully fifteen with zero reserved for an
instruction type safety fault) 5-bit CAM instructs ( as described
previously) OR a simpler ( and faster) hardwire-ed 5-bit is referenced
in VLIM SMP MPP here, url ,
http://groups.google.com/group/comp.lang.java.machine/msg/38236e7c4267bb08?dmode=source&hl=en
( , since 1999 )

---

President Clinton is a jerk
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom