Intel engineer discusses their dual-core design

Rob Stow wrote:

CJT wrote:

Rob Stow wrote:

Bill Davidsen wrote:


keith wrote:


On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:




http://www.macworld.com/news/2005/08...core/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.

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?

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


Probably has something to do with the fact that AMD64 is the hottest
thing right now. Intel just tacked two AMD64-capable cores together
in a MCP, and voila: a cheap AMD64-capable multi-chip package that
they could delude the masses into thinking of as a competitor to
AMD's dual-core chips.

Doing the same thing with the P-M is supposed to eventually happen.
Sort of. Apparently the next generation will be dual-core and
redesigned from the ground up instead of evolved from the P3. Still
haven't heard if it will be AMD64-capable.



I think AMD has finally managed to tarnish "Intel Inside."



Finally ? Where have you been hiding for the last 4 or 5 years ? AMD
has had the better CPUs for desktops and 2-way servers and workstations
since the Athlon XP and MP transitioned from 0.18 to 0.13 microns.
Even before then the Athlon XP and MP outperformed the P4 and Xeon - but
also ran pretty danged hot.

The only CPU market Intel has held the technological edge in for the
past 4 or 5 years has been the mobile market, where the Pentium M has
been king and looks like it will reign for a while longer.

While I tend to agree with you, the perception among the masses has been
different, IMHO. But being "the hottest thing right now" changes that.

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form .

"Robert Redelmeier" wrote in message
m...
In comp.sys.ibm.pc.hardware.chips Terje Mathisen
wrote:
There are several reasons why engineers are very poor at lying:

-) "I'm an engineer, my credibility is my main capital."

-) "Salesmen, la[w]yers, PHBs and several other types that I really
don't like do it, so I want to distance myself from them."

-) It is just so inelegant. :-(

If I absolutely _have_ to lie, it must be by omission: I'll
still tell the truth and nothing but the truth (as I understand
it, of course), but unless you ask me specific questions about
those parts I'm skipping, I might not tell you all of the truth.

So how do you answer when your wife asks: "Does this dress make
me look fat?"

"Of course it doesn't dear!"
(Well, maybe pleasing plump, chubby ... but not "fat" of course.)

The concept of a "duty of truth" is a practical justification.
One really should not lie (even by omission) when one owes information
to someone, and they may be reasonably expected to rely upon it.

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.

A certain amount of lying also eases social interactions.
See the Jim Carrey movie "Liar, liar". Of course, you may
claim that engineers are poor at social interactions

--

... Hank

http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli

Bill Davidsen wrote:
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?

I can't see Intel even having worried about whether it had HT or not.
They just wanted a dual-core in working condition, HT or no HT. The
fact that they were able to get some HT-enabled DC processors out of it
is a bonus as far as they are concerned.

Regarding why P4 instead of P-M? My assumption is that P-M is too
complicated to simply join together side-by-side to get a dual core. I
think P-4 is a major hack job anyways, dual-core or no dual-core. They
mentioned that they layed out the circuit patterns of the P4 on a
computer, and let the computer take care of rearranging it. Whereas the
P4 may have had a lot of places free to attach communications lines
between the cores, and if they don't, all they have to do is have the
computer relayout the design so that places to put comm lines appear in
convenient locations.

Yousuf Khan

Robert Redelmeier wrote:

In comp.sys.ibm.pc.hardware.chips Terje Mathisen wrote:
If I absolutely _have_ to lie, it must be by omission: I'll
still tell the truth and nothing but the truth (as I understand
it, of course), but unless you ask me specific questions about
those parts I'm skipping, I might not tell you all of the truth.


So how do you answer when your wife asks: "Does this dress make
me look fat?"

"I think that other one is even nicer."

The concept of a "duty of truth" is a practical justification.
One really should not lie (even by omission) when one owes information
to someone, and they may be reasonably expected to rely upon it.

Sure.

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.
:-)

Terje

--
-
"almost all programming can be viewed as an exercise in caching"

In article ,
Terje Mathisen 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.

keith 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...core/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

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...core/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

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...core/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

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...core/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

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...core/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