Sign in with
Sign up | Sign in
Your question

Intel engineer discusses their dual-core design

Last response: in CPUs
Share
August 18, 2005 2:39:52 AM

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

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

> http://www.macworld.com/news/2005/08/17/dualcore/index....

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*!

--
Keith
Anonymous
a b à CPUs
August 18, 2005 7:34:22 AM

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

"YKhan" <yjkhan@gmail.com> wrote in message
news:1124308105.322979.179460@o13g2000cwo.googlegroups.com...
> http://www.macworld.com/news/2005/08/17/dualcore/index....
>

I can see why they called it "smithfield" kinda sounds like "smutfield " :) 

Wieeeeeeee very interesting read though... I am just half way wow :D 

Bye,
Skybuck ;) 

(Me looks forward to next intel processor wieeeeeee)
Related resources
Anonymous
a b à CPUs
August 18, 2005 1:59:19 PM

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

keith skrev:

> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>
> > http://www.macworld.com/news/2005/08/17/dualcore/index....
>
> 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.
Anonymous
a b à CPUs
August 18, 2005 3:51:45 PM

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

icerq4a@spray.se wrote:
> The only amazing thing here is that you don't seem to understand the
> article and appear to know nothing about microprocessor development.

Now you've done it. I don't envy your position one bit. :-)

Yousuf Khan
Anonymous
a b à CPUs
August 18, 2005 4:09:04 PM

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

I wonder if that Intel engineer was looking for a new job?

Yousuf Khan
August 18, 2005 11:33:25 PM

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

YKhan wrote:

> I wonder if that Intel engineer was looking for a new job?
>
> Yousuf Khan
>
.... or is now.

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Anonymous
a b à CPUs
August 19, 2005 12:57:51 AM

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

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.08.18.02.39.49.891069@att.bizzzz...
> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>
>> http://www.macworld.com/news/2005/08/17/dualcore/index....
>
> 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*!
>
> --
> Keith

When the PHB only gives you 9 months, you do what you gotta do. And
since this is a desktop thing you do something as much like a dual
processor desktop box as you can. It's a Kluge but it's a Kluge they
needed. He'll get a medal.

del
Anonymous
a b à CPUs
August 19, 2005 2:11:28 AM

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

Del Cecchi wrote:
> When the PHB only gives you 9 months, you do what you gotta do. And
> since this is a desktop thing you do something as much like a dual
> processor desktop box as you can. It's a Kluge but it's a Kluge they
> needed. He'll get a medal.

I bet the management is just now thinking, "yeah, he got our bacon out
of the fire and all with this kludge, but just wish we could train these
engineers to lie occasionally."

Yousuf Khan
Anonymous
a b à CPUs
August 19, 2005 5:27:46 AM

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

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

Better stand under a stream of ice cold waterfall too.
Anonymous
a b à CPUs
August 19, 2005 6:57:04 AM

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

Yousuf Khan <bbbl67@ezrs.com> wrote in news:tdbNe.12965$7R.776216
@news20.bellglobal.com:

> Del Cecchi wrote:
>> When the PHB only gives you 9 months, you do what you gotta do. And
>> since this is a desktop thing you do something as much like a dual
>> processor desktop box as you can. It's a Kluge but it's a Kluge they
>> needed. He'll get a medal.
>
> I bet the management is just now thinking, "yeah, he got our bacon out
> of the fire and all with this kludge, but just wish we could train these
> engineers to lie occasionally."
>
> Yousuf Khan
>

:> Reminds me of something Cringly wrote in Accidental Empires. Something
about why engineers just can't lie. He had a pretty good chapter or two on
this whole subject, how engineers would get all ticked off at management,
and then go tell the public. I can't remeber it exactly... I need to stop
lending my books out as I never get them back.

-grant
Anonymous
a b à CPUs
August 19, 2005 12:11:15 PM

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

Grant Schoep wrote:

> Yousuf Khan <bbbl67@ezrs.com> wrote in news:tdbNe.12965$7R.776216
> @news20.bellglobal.com:
>
>>Del Cecchi wrote:
>>
>>>When the PHB only gives you 9 months, you do what you gotta do. And
>>>since this is a desktop thing you do something as much like a dual
>>>processor desktop box as you can. It's a Kluge but it's a Kluge they
>>>needed. He'll get a medal.

I agree, this might have been a hack but it's an amazing hack.
>>
>>I bet the management is just now thinking, "yeah, he got our bacon out
>>of the fire and all with this kludge, but just wish we could train these
>>engineers to lie occasionally."
>>
> :> Reminds me of something Cringly wrote in Accidental Empires. Something
> about why engineers just can't lie. He had a pretty good chapter or two on
> this whole subject, how engineers would get all ticked off at management,
> and then go tell the public. I can't remeber it exactly... I need to stop
> lending my books out as I never get them back.

There are several reasons why engineers are very poor at lying:

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

-) "Salesmen, layers, 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.

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Anonymous
a b à CPUs
August 19, 2005 4:47:13 PM

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

In comp.sys.ibm.pc.hardware.chips Terje Mathisen <terje.mathisen@hda.hydro.com> 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?" :) 

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

-- Robert
Anonymous
a b à CPUs
August 19, 2005 5:53:20 PM

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

YKhan schrieb:
> I wonder if that Intel engineer was looking for a new job?
>
> Yousuf Khan
>
I'd assume Jonathan presented with full blessing of Intels management.
Playing down Smithfields architecture, blaming the bus for performance
and power issues is actually not a bad idea to prepare the soil for
Paxville, no? While I doubt anybody of the auditorium in Palo Alto was
overly impressed by it, a self-critical Hotchips-presentation by Intel
guarantees press coverage without much probability of looking through an
even paper-thin line of arguments.

KF
Anonymous
a b à CPUs
August 19, 2005 7:28:58 PM

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

keith wrote:
> On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>
>
>>http://www.macworld.com/news/2005/08/17/dualcore/index....
>
>
> 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.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com
Anonymous
a b à CPUs
August 19, 2005 7:28:59 PM

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

On Fri, 19 Aug 2005 15:28:58 GMT, Bill Davidsen
<davidsen@deathstar.prodigy.com> wrote:
[snipped]
>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.

So a D/C P-M DP with ES available early fall '05 (like, soon) hasn't been
publicly announced yet?

I guess I better not talk about one, then...
Anonymous
a b à CPUs
August 19, 2005 8:55:56 PM

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

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....
>>
>>
>>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.
August 19, 2005 9:44:29 PM

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

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/17/dualcore/index....
>>>
>>>
>>>
>>> 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."


--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Anonymous
a b à CPUs
August 19, 2005 10:12:02 PM

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

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/17/dualcore/index....
>>>
>>>
>>>
>>> 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.

The 64 bit is a good point. For many applications AMD dual core or Intel
dual core will be equally satisfactory, and in most cases will perform
about as well as two-way SMP. No delusion needed, they compete.
>
> 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 had hoped for a drop-in dual core P-M for my notebook, but I wasn't
really expecting to get it :-(


--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com
Anonymous
a b à CPUs
August 19, 2005 10:56:44 PM

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

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/17/dualcore/index....
>>>>
>>>>
>>>>
>>>>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.
August 19, 2005 11:24:53 PM

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

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/17/dualcore/index....
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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 che...@prodigy.net.
Anonymous
a b à CPUs
August 20, 2005 12:21:12 AM

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

"Robert Redelmeier" <redelm@ev1.net.invalid> wrote in message
news:lxkNe.3038$r54.2267@newssvr19.news.prodigy.com...
> In comp.sys.ibm.pc.hardware.chips Terje Mathisen
> <terje.mathisen@hda.hydro.com> 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
Anonymous
a b à CPUs
August 20, 2005 1:15:38 AM

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

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
Anonymous
a b à CPUs
August 20, 2005 10:35:06 AM

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

Bill Davidsen <davidsen@deathstar.prodigy.com> writes:
>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?

<speculation> The Pentium M has no multi-processor capabilities, so
making it dual core would have required more work and have had a
longer time-to-market than for the Pentium 4/Xeon. Why does the
Pentium M not have these capabilities when the P6 had them originally?
In the change from the original P6 to the Pentium M they replaced the
bus interface with a Pentium 4 style one; maybe they added one that is
not multiprocessor capable. Or they eliminated multiprocessing
capabilities in other places in order to save power and chip area.
</speculation>

Also, the dual-core chips are for the performance-hungry users. And
the performance chip in Intels marketing is still the Pentium 4 (not
sure if one core of the fastest Pentium D is faster than the fastest
Pentium M, though).

Followups set to comp.arch.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Anonymous
a b à CPUs
August 20, 2005 11:42:49 PM

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

Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips Terje Mathisen <terje.mathisen@hda.hydro.com> 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

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Anonymous
a b à CPUs
August 20, 2005 11:42:50 PM

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.
August 21, 2005 5:53:39 PM

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....
>>
>> 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
August 21, 2005 6:05:29 PM

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....
>>
>>
>> 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
Anonymous
a b à CPUs
August 21, 2005 9:19:16 PM

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....
>>>
>>>
>>>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
Anonymous
a b à CPUs
August 21, 2005 11:07:28 PM

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....
> >>
> >> 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
August 22, 2005 2:32:09 AM

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....
>>>>
>>>>
>>>>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
Anonymous
a b à CPUs
August 22, 2005 10:02:12 AM

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....
> >>
> >>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.
Anonymous
a b à CPUs
August 22, 2005 10:02:13 AM

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:D ebiim$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
Anonymous
a b à CPUs
August 22, 2005 2:44:25 PM

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....
>>>>>
>>>>>
>>>>>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.”
August 23, 2005 1:59:27 AM

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....
>> >>
>> >>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
August 23, 2005 2:04:30 AM

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....
>> >>
>> >> 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
August 23, 2005 2:09:49 AM

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....
>>>>>>
>>>>>>
>>>>>>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
Anonymous
a b à CPUs
August 23, 2005 11:44:44 AM

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
Anonymous
a b à CPUs
August 23, 2005 2:00:53 PM

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
Anonymous
a b à CPUs
August 23, 2005 5:17:59 PM

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
Anonymous
a b à CPUs
August 23, 2005 11:02:57 PM

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

"keith" <krw@att.bizzzz> wrote in message
news:p 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
Anonymous
a b à CPUs
August 24, 2005 4:03:52 AM

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
Anonymous
a b à CPUs
August 24, 2005 10:43:53 AM

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
Anonymous
a b à CPUs
August 24, 2005 10:51:49 AM

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
Anonymous
a b à CPUs
August 24, 2005 4:39:33 PM

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

"keith" <krw@att.bizzzz> wrote in message
news:p 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....
> >> >>
> >> >>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
Anonymous
a b à CPUs
August 24, 2005 4:57:53 PM

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

Yousuf Khan
Anonymous
a b à CPUs
August 24, 2005 5:07:31 PM

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
Anonymous
a b à CPUs
August 24, 2005 7:01:49 PM

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
>
Anonymous
a b à CPUs
August 24, 2005 10:36:54 PM

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

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

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
Anonymous
a b à CPUs
August 24, 2005 11:18:44 PM

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....
> , ))
>
> 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/m...
>
> 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...

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/m...
( , since 1999 )

---

President Clinton is a jerk
!