Intel concedes server business to AMD ;-)

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

On Wed, 25 May 2005 09:30:13 -0400, Robert Myers wrote:

> On Wed, 25 May 2005 13:06:10 GMT, Rob Stow <rob.stow@shaw.ca> wrote:
>
>
>>
>>All that and you still didn't answer his simple question:
>> "Are you saying that an AMD processor is somehow incompatible
>>with an Intel?"
>
> An AMD processor is incompatible with an Intel processor because it
> doesn't say Intel on the package and Intel will tell you to pound sand
> if you have questions about it.
>
> Does that work for you? It works for enough people with money to
> spend and other things to think about.

Ah, the old "no one ever got fired for buying IBM" argument". You've done
well Robert.

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

On Wed, 25 May 2005 09:40:02 -0700, rbmyersusa wrote:

> I use icc, and I use Intel chips. Life is too short to be fussing with
> other chips without good reason. Compatible? Like I said, how do you
> test for it?

Now you're being a bloody fool. One cannot prove perfection, only the
lack of such. BTW, Intel has shown everything other than perfection.

I could give a rat's ass if you spend more than you have to for garbage
processors, but your argument is pure unadulterated FUD! You've lost any
credibility that you ever had here. Sheesh!

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

On Wed, 25 May 2005 20:40:41 -0500, "Del Cecchi"
<dcecchi.nospam@att.net> wrote:

>
><rbmyersusa@gmail.com> wrote in message
>news:1117039202.434847.60080@f14g2000cwb.googlegroups.com...
>>I use icc, and I use Intel chips. Life is too short to be fussing with
>> other chips without good reason. Compatible? Like I said, how do you
>> test for it?
>>
>>
>Same way you test a microsoft service pack before rolling it out company
>wide?
>
In actual fact, and I'm sure you know this, some IT managers have
resisted rolling out significant Microsoft service packs until
Microsoft essentially forced the issue. You may not really know the
consequences of a most software patches until it's too late. That's
life, it seems.

>or for a serious answer you set up some test hardware and beat on it with
>your business critical applications to see if it works or not.
>
Yes, that's what you do. And you can establish likely compatibility
for those circumstances that you have the time to test for.

I made the comment about icc as an example of why that strategy might
not always work. How do I know what Intel is going to do with its
compiler? They're not going to worry about compatibility with AMD,
that's for sure. I can't test for what intel is going to do next, and
neither can anyone else, nor can I even really tell what issues there
might be in the version of the compiler I have to day, because I don't
always know what *I'm* going to do next.

There aren't that many people out there with an intel compiler as part
of their business logic? Probably not. Software vendors who are not
Intel aren't going to be looking for ways to make life difficult for
non-Intel chips, but that doesn't mean they can't stumble over them,
and most of the testing is going to be done with Intel chips. Can you
disagree with that?

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

On Wed, 25 May 2005 22:19:10 -0400, keith <krw@att.bizzzz> wrote:

>On Wed, 25 May 2005 09:30:13 -0400, Robert Myers wrote:
>
>> On Wed, 25 May 2005 13:06:10 GMT, Rob Stow <rob.stow@shaw.ca> wrote:
>>
>>
>>>
>>>All that and you still didn't answer his simple question:
>>> "Are you saying that an AMD processor is somehow incompatible
>>>with an Intel?"
>>
>> An AMD processor is incompatible with an Intel processor because it
>> doesn't say Intel on the package and Intel will tell you to pound sand
>> if you have questions about it.
>>
>> Does that work for you? It works for enough people with money to
>> spend and other things to think about.
>
>Ah, the old "no one ever got fired for buying IBM" argument". You've done
>well Robert.

Thank you.

I don't decide how the world works. Intel has the most capacity.
Intel produces most of the world's x86-compatible processors. That
situation isn't likely to change any time soon. Absent a compelling
reason to do otherwise, managers will buy the actual chip, and not one
that is compatible. What is the actual chip? At the moment, it's one
made by Intel.

The deck is stacked heavily in favor of the dominant supplier. That's
where most of the testing will be done, that's where most of the
support resources are, and that's the direction people will lean when
they've got too many other things to think about.

Someone who works with very large applications was recently singing
the praises of an AMD processor recently rolled in the door. Three
messages there: he really likes the AMD processor, he couldn't afford
to rely on someone else's assurance of compatibility, and he just
started testing AMD processors.

I don't decide these things. Markets do.

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

On Thu, 26 May 2005 08:44:10 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Wed, 25 May 2005 20:40:41 -0500, "Del Cecchi"
><dcecchi.nospam@att.net> wrote:
>
>>
>><rbmyersusa@gmail.com> wrote in message
>>news:1117039202.434847.60080@f14g2000cwb.googlegroups.com...
>>>I use icc, and I use Intel chips. Life is too short to be fussing with
>>> other chips without good reason. Compatible? Like I said, how do you
>>> test for it?
>>>
>>>
>>Same way you test a microsoft service pack before rolling it out company
>>wide?
>>
>In actual fact, and I'm sure you know this, some IT managers have
>resisted rolling out significant Microsoft service packs until
>Microsoft essentially forced the issue. You may not really know the
>consequences of a most software patches until it's too late. That's
>life, it seems.
>
>>or for a serious answer you set up some test hardware and beat on it with
>>your business critical applications to see if it works or not.
>>
>Yes, that's what you do. And you can establish likely compatibility
>for those circumstances that you have the time to test for.
>
>I made the comment about icc as an example of why that strategy might
>not always work. How do I know what Intel is going to do with its
>compiler? They're not going to worry about compatibility with AMD,
>that's for sure. I can't test for what intel is going to do next, and
>neither can anyone else, nor can I even really tell what issues there
>might be in the version of the compiler I have to day, because I don't
>always know what *I'm* going to do next.
>
>There aren't that many people out there with an intel compiler as part
>of their business logic? Probably not. Software vendors who are not
>Intel aren't going to be looking for ways to make life difficult for
>non-Intel chips, but that doesn't mean they can't stumble over them,
>and most of the testing is going to be done with Intel chips. Can you
>disagree with that?

OK, when you say "Intel compiler" I assume you mean the (acquired) Digital
compilers... because the home-baked Intel compilers/plugins were broken
since forever. No ISV would go near them... and for the same reasons, now
approaches the newer Digital-come-Intel versions with suspicion. One
definitely stays away from "optimizations" which are obviously, or even
suspected to be, rigged for benchmark err, enhancement.

Hell, there are other compilers to use anyway which are designed for real
work and with known legacy compatiblity, if that comes into it. It's not
like Intel can suddenly add a new instruction sub-set and expect the whole
world to just switch/upgrade. Life as an ISV is not that simple: one tends
to concentrate on the core (legacy) instruction set as the base code, with
enhanced instructions as a possible alternate code-path IFF the client
wants to take the optional risk... and if a client has AMD CPUs you make
the software work with them, though IME that has never been an issue.

Besides, the x86-64 instruction set is an AMD invention - the world is
changing... Intel is the sub-licensee now!🙂 Which one are you going to
trust... especially if you count the Intel blunders on addressing and
memory mapping with EM64T and with a chipset in the CPU->memory path to add
some uncertainty.

I'm sorry but your FUD is misplaced and your emperor's clothes are barely
visible. Do let us know of anything you stumble upon... because in 8 years
or so of "pounding" on AMD K6, K7 and K8 CPUs I'm still stumble-free!

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

On Thu, 26 May 2005 08:58:35 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Wed, 25 May 2005 22:19:10 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Wed, 25 May 2005 09:30:13 -0400, Robert Myers wrote:
>>
>>> On Wed, 25 May 2005 13:06:10 GMT, Rob Stow <rob.stow@shaw.ca> wrote:
>>>
>>>
>>>>
>>>>All that and you still didn't answer his simple question:
>>>> "Are you saying that an AMD processor is somehow incompatible
>>>>with an Intel?"
>>>
>>> An AMD processor is incompatible with an Intel processor because it
>>> doesn't say Intel on the package and Intel will tell you to pound sand
>>> if you have questions about it.
>>>
>>> Does that work for you? It works for enough people with money to
>>> spend and other things to think about.
>>
>>Ah, the old "no one ever got fired for buying IBM" argument". You've done
>>well Robert.
>
>Thank you.
>
>I don't decide how the world works. Intel has the most capacity.
>Intel produces most of the world's x86-compatible processors. That
>situation isn't likely to change any time soon. Absent a compelling
>reason to do otherwise, managers will buy the actual chip, and not one
>that is compatible. What is the actual chip? At the moment, it's one
>made by Intel.

WRONG! You have not been paying attention. AMD64, EM64T, x86-64 or
whatever you want to call it is not an Intel innovation. In fact Intel
made a bit of a hash of trying to catch up here... between the I/O memory
mapping debacle and the chipsets which can't do >32-bit addressing...
paired with CPUs which can. Hell it's now quite clear that they added
AMD64 to the wrong line of CPUs and left themselves with an even steeper
curve to err, learn. Adding it to Pentium-M and conjuring up yet another
new "architecture" with all the usual marketing gimmickry is wearing
thin... for me anyway. I'll stick to something I know works and which is
err, supported by the OS vendors.

>The deck is stacked heavily in favor of the dominant supplier. That's
>where most of the testing will be done, that's where most of the
>support resources are, and that's the direction people will lean when
>they've got too many other things to think about.

Hmm, the rear-guard option?... a formula for success?

>Someone who works with very large applications was recently singing
>the praises of an AMD processor recently rolled in the door. Three
>messages there: he really likes the AMD processor, he couldn't afford
>to rely on someone else's assurance of compatibility, and he just
>started testing AMD processors.

Some people are always late to the game!🙂

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

On Thu, 26 May 2005 20:27:42 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>On Thu, 26 May 2005 08:44:10 -0400, Robert Myers <rmyers1400@comcast.net>
>wrote:
>

>>
>>I made the comment about icc as an example of why that strategy might
>>not always work. How do I know what Intel is going to do with its
>>compiler? They're not going to worry about compatibility with AMD,
>>that's for sure. I can't test for what intel is going to do next, and
>>neither can anyone else, nor can I even really tell what issues there
>>might be in the version of the compiler I have to day, because I don't
>>always know what *I'm* going to do next.
>>
>>There aren't that many people out there with an intel compiler as part
>>of their business logic? Probably not. Software vendors who are not
>>Intel aren't going to be looking for ways to make life difficult for
>>non-Intel chips, but that doesn't mean they can't stumble over them,
>>and most of the testing is going to be done with Intel chips. Can you
>>disagree with that?
>
>OK, when you say "Intel compiler" I assume you mean the (acquired) Digital
>compilers... because the home-baked Intel compilers/plugins were broken
>since forever. No ISV would go near them... and for the same reasons, now
>approaches the newer Digital-come-Intel versions with suspicion. One
>definitely stays away from "optimizations" which are obviously, or even
>suspected to be, rigged for benchmark err, enhancement.
>

I mean icc. I thought the provenance of icc was the Portland Compiler
Group or some such. And, yes, the purpose of icc is to get good
benchmarks. It's fun to play with.

But that's the world I live in, George. I simply picked an example
from my own experience. Would you prefer that I talk about things I
don't know about? I can do that, too. ;-).

>Hell, there are other compilers to use anyway which are designed for real
>work and with known legacy compatiblity, if that comes into it. It's not
>like Intel can suddenly add a new instruction sub-set and expect the whole
>world to just switch/upgrade. Life as an ISV is not that simple: one tends
>to concentrate on the core (legacy) instruction set as the base code, with
>enhanced instructions as a possible alternate code-path IFF the client
>wants to take the optional risk... and if a client has AMD CPUs you make
>the software work with them, though IME that has never been an issue.
>
>Besides, the x86-64 instruction set is an AMD invention - the world is
>changing... Intel is the sub-licensee now!🙂 Which one are you going to
>trust... especially if you count the Intel blunders on addressing and
>memory mapping with EM64T and with a chipset in the CPU->memory path to add
>some uncertainty.
>
>I'm sorry but your FUD is misplaced and your emperor's clothes are barely
>visible. Do let us know of anything you stumble upon... because in 8 years
>or so of "pounding" on AMD K6, K7 and K8 CPUs I'm still stumble-free!

What FUD? Like you think I work for Intel? I do have an investment
in Itanium, and an investment in Intel compiler technology that goes
along with it. Other than that, what do I care? I never liked
NetBurst, except for the memory bandwidth. I'm a market observer, not
a market shaper.

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

On Thu, 26 May 2005 20:27:46 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>On Thu, 26 May 2005 08:58:35 -0400, Robert Myers <rmyers1400@comcast.net>
>wrote:
>
>>On Wed, 25 May 2005 22:19:10 -0400, keith <krw@att.bizzzz> wrote:
>>
>>>On Wed, 25 May 2005 09:30:13 -0400, Robert Myers wrote:
>>>
>>>> On Wed, 25 May 2005 13:06:10 GMT, Rob Stow <rob.stow@shaw.ca> wrote:
>>>>
>>>>
>>>>>
>>>>>All that and you still didn't answer his simple question:
>>>>> "Are you saying that an AMD processor is somehow incompatible
>>>>>with an Intel?"
>>>>
>>>> An AMD processor is incompatible with an Intel processor because it
>>>> doesn't say Intel on the package and Intel will tell you to pound sand
>>>> if you have questions about it.
>>>>
>>>> Does that work for you? It works for enough people with money to
>>>> spend and other things to think about.
>>>
>>>Ah, the old "no one ever got fired for buying IBM" argument". You've done
>>>well Robert.
>>
>>Thank you.
>>
>>I don't decide how the world works. Intel has the most capacity.
>>Intel produces most of the world's x86-compatible processors. That
>>situation isn't likely to change any time soon. Absent a compelling
>>reason to do otherwise, managers will buy the actual chip, and not one
>>that is compatible. What is the actual chip? At the moment, it's one
>>made by Intel.
>
>WRONG! You have not been paying attention. AMD64, EM64T, x86-64 or
>whatever you want to call it is not an Intel innovation.

You surely know that I know that history.

>In fact Intel
>made a bit of a hash of trying to catch up here... between the I/O memory
>mapping debacle and the chipsets which can't do >32-bit addressing...
>paired with CPUs which can. Hell it's now quite clear that they added
>AMD64 to the wrong line of CPUs and left themselves with an even steeper
>curve to err, learn. Adding it to Pentium-M and conjuring up yet another
>new "architecture" with all the usual marketing gimmickry is wearing
>thin... for me anyway. I'll stick to something I know works and which is
>err, supported by the OS vendors.
>
Wearing thin? You never liked it.

The bottom line here isn't what you or I think. The bottom line is
fab capacity. The balance is changing? Sure, but slowly. No
surprises.

>>The deck is stacked heavily in favor of the dominant supplier. That's
>>where most of the testing will be done, that's where most of the
>>support resources are, and that's the direction people will lean when
>>they've got too many other things to think about.
>
>Hmm, the rear-guard option?... a formula for success?
>
Avis did good with their "We're No. 2" campaign, but they're still No.
2.

>>Someone who works with very large applications was recently singing
>>the praises of an AMD processor recently rolled in the door. Three
>>messages there: he really likes the AMD processor, he couldn't afford
>>to rely on someone else's assurance of compatibility, and he just
>>started testing AMD processors.
>
>Some people are always late to the game!🙂

He doesn't think much of Intel compilers, either.

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

On Wed, 25 May 2005 15:59:39 -0400, George Macdonald wrote:

> On 25 May 2005 09:40:02 -0700, rbmyersusa@gmail.com wrote:
>
>>I use icc, and I use Intel chips. Life is too short to be fussing with
>>other chips without good reason. Compatible? Like I said, how do you
>>test for it?
>
> That old bait is getting really stale and smelly Robert. I was sure you
> could do better.

Indeed. ...and he keep it in the sun too.

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

On Thu, 26 May 2005 08:58:35 -0400, Robert Myers wrote:

> On Wed, 25 May 2005 22:19:10 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Wed, 25 May 2005 09:30:13 -0400, Robert Myers wrote:
>>
>>> On Wed, 25 May 2005 13:06:10 GMT, Rob Stow <rob.stow@shaw.ca> wrote:
>>>
>>>
>>>>
>>>>All that and you still didn't answer his simple question:
>>>> "Are you saying that an AMD processor is somehow incompatible
>>>>with an Intel?"
>>>
>>> An AMD processor is incompatible with an Intel processor because it
>>> doesn't say Intel on the package and Intel will tell you to pound sand
>>> if you have questions about it.
>>>
>>> Does that work for you? It works for enough people with money to
>>> spend and other things to think about.
>>
>>Ah, the old "no one ever got fired for buying IBM" argument". You've done
>>well Robert.
>
> Thank you.
>
> I don't decide how the world works. Intel has the most capacity.
> Intel produces most of the world's x86-compatible processors. That
> situation isn't likely to change any time soon. Absent a compelling
> reason to do otherwise, managers will buy the actual chip, and not one
> that is compatible. What is the actual chip? At the moment, it's one
> made by Intel.

Ah, so you admit that you're a brainless "me-too". We've been suspecting
as much for a half-decade. The world turns, and your end isn't keeping
up.

> The deck is stacked heavily in favor of the dominant supplier. That's
> where most of the testing will be done, that's where most of the support
> resources are, and that's the direction people will lean when they've
> got too many other things to think about.

That says *zilch* about compatibility. You're grasping and straws.
....while attempting to hijack the argument into you litttle corner.

> Someone who works with very large applications was recently singing the
> praises of an AMD processor recently rolled in the door. Three messages
> there: he really likes the AMD processor, he couldn't afford to rely on
> someone else's assurance of compatibility, and he just started testing
> AMD processors.

Wonderful. What's your point?

> I don't decide these things. Markets do.

....and you follow the "market" like a bitch in heat. I guess I always
knew that about you. No imagination. What I have now is good enough.
....and then you complain out the other side of your mouth about
optimizations. Sheesh! You're a piece of work Robert.

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

On Thu, 26 May 2005 20:58:22 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Thu, 26 May 2005 20:27:42 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>On Thu, 26 May 2005 08:44:10 -0400, Robert Myers <rmyers1400@comcast.net>
>>wrote:
>>
>
>>>
>>>I made the comment about icc as an example of why that strategy might
>>>not always work. How do I know what Intel is going to do with its
>>>compiler? They're not going to worry about compatibility with AMD,
>>>that's for sure. I can't test for what intel is going to do next, and
>>>neither can anyone else, nor can I even really tell what issues there
>>>might be in the version of the compiler I have to day, because I don't
>>>always know what *I'm* going to do next.
>>>
>>>There aren't that many people out there with an intel compiler as part
>>>of their business logic? Probably not. Software vendors who are not
>>>Intel aren't going to be looking for ways to make life difficult for
>>>non-Intel chips, but that doesn't mean they can't stumble over them,
>>>and most of the testing is going to be done with Intel chips. Can you
>>>disagree with that?
>>
>>OK, when you say "Intel compiler" I assume you mean the (acquired) Digital
>>compilers... because the home-baked Intel compilers/plugins were broken
>>since forever. No ISV would go near them... and for the same reasons, now
>>approaches the newer Digital-come-Intel versions with suspicion. One
>>definitely stays away from "optimizations" which are obviously, or even
>>suspected to be, rigged for benchmark err, enhancement.
>>
>
>I mean icc. I thought the provenance of icc was the Portland Compiler
>Group or some such. And, yes, the purpose of icc is to get good
>benchmarks. It's fun to play with.

Sorry but I was thinking Fortran and assuming that Intel got their C/C++
from the same place.

>But that's the world I live in, George. I simply picked an example
>from my own experience. Would you prefer that I talk about things I
>don't know about? I can do that, too. ;-).

OK but in that case, the world you live in does not seem relevant to
software vendors' choice of compiler nor your speculations on whether they
will "stumble" with an AMD CPU.

>>Hell, there are other compilers to use anyway which are designed for real
>>work and with known legacy compatiblity, if that comes into it. It's not
>>like Intel can suddenly add a new instruction sub-set and expect the whole
>>world to just switch/upgrade. Life as an ISV is not that simple: one tends
>>to concentrate on the core (legacy) instruction set as the base code, with
>>enhanced instructions as a possible alternate code-path IFF the client
>>wants to take the optional risk... and if a client has AMD CPUs you make
>>the software work with them, though IME that has never been an issue.
>>
>>Besides, the x86-64 instruction set is an AMD invention - the world is
>>changing... Intel is the sub-licensee now!🙂 Which one are you going to
>>trust... especially if you count the Intel blunders on addressing and
>>memory mapping with EM64T and with a chipset in the CPU->memory path to add
>>some uncertainty.
>>
>>I'm sorry but your FUD is misplaced and your emperor's clothes are barely
>>visible. Do let us know of anything you stumble upon... because in 8 years
>>or so of "pounding" on AMD K6, K7 and K8 CPUs I'm still stumble-free!
>
>What FUD? Like you think I work for Intel? I do have an investment
>in Itanium, and an investment in Intel compiler technology that goes
>along with it. Other than that, what do I care? I never liked
>NetBurst, except for the memory bandwidth. I'm a market observer, not
>a market shaper.

Huh? I thought the discussion was about mainstream x86 CPUs, both Intel
and AMD. You clearly suggested that a reason to stay with Intel CPUs was
to avoid stumbling over some imagined incompatibility... whether with an
Intel or non-Intel compiler. That's FUD!

In fact for the x86-64 environment, M$ and ISVs have been compiling and
running using AMD64 for almost 2 years now. Does that mean that end users
should now stay away from EM64T, lest they "stumble" over some glitch in
Intel's x86-64 CPU implementation?🙂

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

On Thu, 26 May 2005 21:04:40 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Thu, 26 May 2005 20:27:46 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>On Thu, 26 May 2005 08:58:35 -0400, Robert Myers <rmyers1400@comcast.net>
>>wrote:
>>
>>>On Wed, 25 May 2005 22:19:10 -0400, keith <krw@att.bizzzz> wrote:
>>>
>>>>On Wed, 25 May 2005 09:30:13 -0400, Robert Myers wrote:
>>>>
>>>>> On Wed, 25 May 2005 13:06:10 GMT, Rob Stow <rob.stow@shaw.ca> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>All that and you still didn't answer his simple question:
>>>>>> "Are you saying that an AMD processor is somehow incompatible
>>>>>>with an Intel?"
>>>>>
>>>>> An AMD processor is incompatible with an Intel processor because it
>>>>> doesn't say Intel on the package and Intel will tell you to pound sand
>>>>> if you have questions about it.
>>>>>
>>>>> Does that work for you? It works for enough people with money to
>>>>> spend and other things to think about.
>>>>
>>>>Ah, the old "no one ever got fired for buying IBM" argument". You've done
>>>>well Robert.
>>>
>>>Thank you.
>>>
>>>I don't decide how the world works. Intel has the most capacity.
>>>Intel produces most of the world's x86-compatible processors. That
>>>situation isn't likely to change any time soon. Absent a compelling
>>>reason to do otherwise, managers will buy the actual chip, and not one
>>>that is compatible. What is the actual chip? At the moment, it's one
>>>made by Intel.
>>
>>WRONG! You have not been paying attention. AMD64, EM64T, x86-64 or
>>whatever you want to call it is not an Intel innovation.
>
>You surely know that I know that history.

So you must know that the "actual chip" has changed color.🙂

>>In fact Intel
>>made a bit of a hash of trying to catch up here... between the I/O memory
>>mapping debacle and the chipsets which can't do >32-bit addressing...
>>paired with CPUs which can. Hell it's now quite clear that they added
>>AMD64 to the wrong line of CPUs and left themselves with an even steeper
>>curve to err, learn. Adding it to Pentium-M and conjuring up yet another
>>new "architecture" with all the usual marketing gimmickry is wearing
>>thin... for me anyway. I'll stick to something I know works and which is
>>err, supported by the OS vendors.
>>
>Wearing thin? You never liked it.

What's to like about Intel's marketing angles?... so feeble. Either their
tech experts are sheep or there are a lot of angry people there: "disagree
& commit".🙂

>The bottom line here isn't what you or I think. The bottom line is
>fab capacity. The balance is changing? Sure, but slowly. No
>surprises.

We'll see. There are lots of "ifs" here on both sides. Intel is to
convert more fabs to 300mm 90nm, with 65nm for next gen and AMD has Fab 36
and Chartered's financial status to worry about.

>>>The deck is stacked heavily in favor of the dominant supplier. That's
>>>where most of the testing will be done, that's where most of the
>>>support resources are, and that's the direction people will lean when
>>>they've got too many other things to think about.
>>
>>Hmm, the rear-guard option?... a formula for success?
>>
>Avis did good with their "We're No. 2" campaign, but they're still No.
>2.

Hmm, Intel's future??🙂

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

On Fri, 27 May 2005 04:08:48 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>On Thu, 26 May 2005 21:04:40 -0400, Robert Myers <rmyers1400@comcast.net>
>wrote:
>
>>On Thu, 26 May 2005 20:27:46 -0400, George Macdonald
>><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>>
>>>On Thu, 26 May 2005 08:58:35 -0400, Robert Myers <rmyers1400@comcast.net>
>>>wrote:
>>>

>>>>
>>>>I don't decide how the world works. Intel has the most capacity.
>>>>Intel produces most of the world's x86-compatible processors. That
>>>>situation isn't likely to change any time soon. Absent a compelling
>>>>reason to do otherwise, managers will buy the actual chip, and not one
>>>>that is compatible. What is the actual chip? At the moment, it's one
>>>>made by Intel.
>>>
>>>WRONG! You have not been paying attention. AMD64, EM64T, x86-64 or
>>>whatever you want to call it is not an Intel innovation.
>>
>>You surely know that I know that history.
>
>So you must know that the "actual chip" has changed color.🙂
>
That would be true if history decided these things. History doesn't
decide these things.

>>>In fact Intel
>>>made a bit of a hash of trying to catch up here... between the I/O memory
>>>mapping debacle and the chipsets which can't do >32-bit addressing...
>>>paired with CPUs which can. Hell it's now quite clear that they added
>>>AMD64 to the wrong line of CPUs and left themselves with an even steeper
>>>curve to err, learn. Adding it to Pentium-M and conjuring up yet another
>>>new "architecture" with all the usual marketing gimmickry is wearing
>>>thin... for me anyway. I'll stick to something I know works and which is
>>>err, supported by the OS vendors.
>>>
>>Wearing thin? You never liked it.
>
>What's to like about Intel's marketing angles?... so feeble. Either their
>tech experts are sheep or there are a lot of angry people there: "disagree
>& commit".🙂
>

Who knows? I'll bet AMD is no fun to work for, either. Part of the
reason I made the original post in this thread is that it was striking
that Intel wasn't even really trying to fake it. It's easy to find
statements to the effect that the corporate culture has changed, and
then there are the well-known management memos to employees. I've
made the comparison to the auto industry before, but it seems to fit.
The business has become boring, and the excitement is all artificial.
What will AMD do for excitement if it becomes number 1?

>>The bottom line here isn't what you or I think. The bottom line is
>>fab capacity. The balance is changing? Sure, but slowly. No
>>surprises.
>
>We'll see. There are lots of "ifs" here on both sides. Intel is to
>convert more fabs to 300mm 90nm, with 65nm for next gen and AMD has Fab 36
>and Chartered's financial status to worry about.
>
>>>>The deck is stacked heavily in favor of the dominant supplier. That's
>>>>where most of the testing will be done, that's where most of the
>>>>support resources are, and that's the direction people will lean when
>>>>they've got too many other things to think about.
>>>
>>>Hmm, the rear-guard option?... a formula for success?
>>>
>>Avis did good with their "We're No. 2" campaign, but they're still No.
>>2.
>
>Hmm, Intel's future??🙂

Probably about the same as GM's, I'd guess.

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

On Thu, 26 May 2005 21:48:17 -0400, keith <krw@att.bizzzz> wrote:

>On Thu, 26 May 2005 10:16:27 -0400, Robert Myers wrote:
>

>>
>> At one point Folding at Home was seeking clients with P4's, because
>> that's what they had optimized the code for. Why not optimize for an
>> AMD processor (other than the fact that it might not do as well for
>> that kind of application?)? Because there are tons of P4's out there.
>
>Oh, goodie. Now you're bringing up another canard. Who cares about
>optimization of free cycles. Don't tell me you're stupid enough to fall
>for this.
>
I provided an example the most common case getting the attention. How
that got warped in your mind to my claiming that optimization of free
cycles is important is something you'll have to work out without my
assistance. The most common case gets that attention. The most
common case is still Intel.

>> In the end, Keith, markets make the rules, individuals don't.
>
>Indeed. Your Itanic is just where it belongs. When was the first time I
>told you this? Intel still hasn't recovered from this abject stupidity.
>I really do think they're *still* in denial.

So, let's see? Markets are smart when you agree with them. Markets
are stupid when you don't. The world is full of people who think that
others are smart when they agree with them and stupid when they don't.

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

According to Del Cecchi <dcecchi.nospam@att.net>:
> That brings up an interesting question. Say I had a copy of PCdos or MSdos,
> and a copy of some software, say PCwrite or ezriter or something of vintage
> 1982 along with some files created with said software could I boot that OS
> and run that software and edit those files (pretending I have somehow
> attached a 5.25 floppy instead of the 3.5 thus having no media problem) on a
> modern PC, circa the XP era?

I think the most common problem is a bad timing loop, since the software was
not expecting CPUs to run in the GHz clock range.

CPUs has gotten so fast, though, that you can emulate the old machine
itself. I have had success with DOSBox for old games, which is about the
trickiest software to get working.

http://dosbox.sourceforge.net/

There's even a version with MT-32 emulation if you search for it (totally
off-topic 🙂 )

There's also bochs, which is supposedly a more complete emulator, but I
haven't played around with it much.

http://bochs.sourceforge.net/

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

On Fri, 27 May 2005 06:48:19 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Fri, 27 May 2005 04:08:48 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>On Thu, 26 May 2005 21:04:40 -0400, Robert Myers <rmyers1400@comcast.net>
>>wrote:
>>
>>>On Thu, 26 May 2005 20:27:46 -0400, George Macdonald
>>><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>>>
>>>>On Thu, 26 May 2005 08:58:35 -0400, Robert Myers <rmyers1400@comcast.net>
>>>>wrote:
>>>>
>
>>>>>
>>>>>I don't decide how the world works. Intel has the most capacity.
>>>>>Intel produces most of the world's x86-compatible processors. That
>>>>>situation isn't likely to change any time soon. Absent a compelling
>>>>>reason to do otherwise, managers will buy the actual chip, and not one
>>>>>that is compatible. What is the actual chip? At the moment, it's one
>>>>>made by Intel.
>>>>
>>>>WRONG! You have not been paying attention. AMD64, EM64T, x86-64 or
>>>>whatever you want to call it is not an Intel innovation.
>>>
>>>You surely know that I know that history.
>>
>>So you must know that the "actual chip" has changed color.🙂
>>
>That would be true if history decided these things. History doesn't
>decide these things.

No, in the context that you have used "actual chip" in this thread, the
AMD64 is the definitive article - the EM64T is the copy.

>>>>In fact Intel
>>>>made a bit of a hash of trying to catch up here... between the I/O memory
>>>>mapping debacle and the chipsets which can't do >32-bit addressing...
>>>>paired with CPUs which can. Hell it's now quite clear that they added
>>>>AMD64 to the wrong line of CPUs and left themselves with an even steeper
>>>>curve to err, learn. Adding it to Pentium-M and conjuring up yet another
>>>>new "architecture" with all the usual marketing gimmickry is wearing
>>>>thin... for me anyway. I'll stick to something I know works and which is
>>>>err, supported by the OS vendors.
>>>>
>>>Wearing thin? You never liked it.
>>
>>What's to like about Intel's marketing angles?... so feeble. Either their
>>tech experts are sheep or there are a lot of angry people there: "disagree
>>& commit".🙂
>>
>
>Who knows? I'll bet AMD is no fun to work for, either. Part of the
>reason I made the original post in this thread is that it was striking
>that Intel wasn't even really trying to fake it. It's easy to find
>statements to the effect that the corporate culture has changed, and
>then there are the well-known management memos to employees. I've
>made the comparison to the auto industry before, but it seems to fit.
>The business has become boring, and the excitement is all artificial.
>What will AMD do for excitement if it becomes number 1?

No doubt AMD has the potential to get as ugly. As for Intel I judge them
on their behavior rather than "statements" - if the shoe fits.......

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

George Macdonald wrote:

> You just won't give up with this "advantage" of volume... reminds me of
> Lenin's famous quote: "quantity has a quality all of its own".🙂

Hmmm. I've heard that attribute to both Stalin and Mao, but
never to Lenin.

Earliest reference I've found over the years (not that I did a
thorough search) was in Stalin talking about how the Russian T-34
tank compared to the qualitatively superior German tanks.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

"Rob Stow" <rob.stow@shaw.ca> wrote in message
news:jXeme.1508529$8l.795541@pd7tw1no...
> George Macdonald wrote:
>
>> You just won't give up with this "advantage" of volume... reminds me
>> of
>> Lenin's famous quote: "quantity has a quality all of its own".🙂
>
> Hmmm. I've heard that attribute to both Stalin and Mao, but never to
> Lenin.
>
> Earliest reference I've found over the years (not that I did a thorough
> search) was in Stalin talking about how the Russian T-34 tank compared
> to the qualitatively superior German tanks.

Lenin, Stalin, Mao. What difference does it make which insane genocidal
murderous dictator said it? It isn't true any more than most of the
things they said.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sun, 29 May 2005 07:06:28 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Sun, 29 May 2005 01:49:25 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
<<snip>>

>>Look back in the thread for *your* use and definition of "incompatible" -
>>no it wasn't I who started this. Both AMD & Intel sell actual x86 chips
>>which both run the same code; if a P4 is an "actual Intel chip" an Athlon64
>>is an "actual AMD chip". No it's not something else and the ownership of
>>the definition has just formally changed... to shared?
>>
>It's your claim, George. You can't demand that I do the work to back
>up your claim, can you? In any case, I'm not going to. Google says
>that the word "incompatible" belongs to you.

4bv89155v8hviq15hg3kv810ru1gos26q2@4ax.com - "An AMD processor is
incompatible with an Intel processor because...." seems to predate anything
I've said.

>>I've no idea what that is supposed to mean nor what mission you have in
>>mind. You can't possibly argue with the fact that the Athlon64/Opteron
>>works... rather well in fact. Whether you've personally tried/tested one
>>has nothing to do with the facts. Hell even Intel's new CEO has resorted
>>to the "don't worry chaps, we'll catch them up [... in about 18 months]"...
>>funny that: AMD is going to stand still to give them a fair whack at
>>it.:-[]
>
>What has *any* of that got to do with the fact that most people are
>going to test for mission-critical applications?

Like I said, the AMD CPU works... at least as well as any Intel version; in
fact an examination of specified operating parameters and current empirical
evidence indicates that the Intel product is subject to higher thermal
stresses... certainly something to be taken into account. Mission
critical, however, would cover many other more likely failure points in a
system infrastructure than the CPU. I'd expect that there are even some
who would rule out any x86 system for that task. You'll have to give
evidence: of actual failure, or why an AMD system would be more
susceptible.

<<snip>>

>>You know damned well that nobody is applying labels here - no need to
>>address that. What I'm objecting to is your overt, repetitious use of
>>"actual product" and the suggestion that buyers, the sheep notwithstanding,
>>perceive the definition of that according to "largest sales".
>>
>'Fraid they do, George.

We'll just have to disagree here. The fact that Intel dumps millions of
chips at knock-down prices through Dell is irrelevant to the functionality
which defines "actual product".

>>>That buyers are biased toward products with more market share seems so
>>>self-evident in this case, that I don't know why we're discussing it.
>>>AMD has the better product. It should sweep the market. It isn't. It
>>>won't. Same could be said for GM cars for decades (although they sure
>>>have taken a beating).
>>
>>To say "it won't" (ever) is absurd... though sweep is obviously not
>>practical given current production. GM is not really a good analogy --
>>Delphi, Valeo or Nippon-Denso would be better -- but I'm sure you haven't
>>missed the fact that Toyota & Honda started small and now own the
>>automobile market - it took a bit of time to ramp to that level... and even
>>the sheep followed. GM makes trucks for a living.
>>
>"It won't" in this instance is ambiguous. Could the entire
>infrastructure of the semiconductor industry change? Sure. It's
>happened in lots of industries. It takes time. Short of that
>happening, there should be a shortage of AMD chips. I don't see that
>heppening, either. This really does remind me of sports talk radio.

You obviously haven't tried to buy an AMD CPU recently - "shortage" is only
a relative term here but there is obvious binning which is causing
shortages in some of the more popular mid-priced Athlon64s... probably good
for AMD's ASP.

>>You just won't give up with this "advantage" of volume... reminds me of
>>Lenin's famous quote: "quantity has a quality all of its own".🙂 Nope,
>>the only advantage here is performance/$ and your, again repetitious,
>>insistence on "problems that might show up" is ludicrous in the face of
>>proven facts. What problems?... enumerate please... or give it up!... even
>>better: buy an Athlon64 and tell us what you find wrong with it. Your
>>misplaced suspicion is ugly, well past due date and not at all creditable.
>>
>What, now you're smearing me with "commie" labels? Are you _sure_
>you've never worked in advertising, marketing, public relations,
>fundraising, or some other manipulative business?

Whoever the quote is due to matters not - would Napoleon make you feel
better?🙂 Feigned indignation is no substitute for facts.

>>You think M$ was using Intel's prototype chips to develop XP-64 - I don't
>>think so;
>
>*Where* did I ever say *that*? You're seeing things (commies under
>the bed, perhaps?). Or are you claiming to be able to be able to read
>my mind? Or are you just putting words in my mouth?

Sorry if that came out wrong - should have used a question mark, since it
*was* a question... which I thought relevant in the face of your "actual
product" claims.

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

On Sun, 29 May 2005 08:20:31 GMT, Rob Stow <rob.stow@shaw.ca> wrote:

>George Macdonald wrote:
>
>> You just won't give up with this "advantage" of volume... reminds me of
>> Lenin's famous quote: "quantity has a quality all of its own".🙂
>
>Hmmm. I've heard that attribute to both Stalin and Mao, but
>never to Lenin.
>
>Earliest reference I've found over the years (not that I did a
>thorough search) was in Stalin talking about how the Russian T-34
>tank compared to the qualitatively superior German tanks.

It's hard to tell - I'd first seen/heard it attributed to Lenin but now I
see even Napolen is given credit. Dunno where to go to get the
authoritative answer.

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

On Mon, 30 May 2005 02:02:14 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>On Sun, 29 May 2005 07:06:28 -0400, Robert Myers <rmyers1400@comcast.net>
>wrote:
>
>>On Sun, 29 May 2005 01:49:25 -0400, George Macdonald
>><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>>
><<snip>>
>
>>>Look back in the thread for *your* use and definition of "incompatible" -
>>>no it wasn't I who started this. Both AMD & Intel sell actual x86 chips
>>>which both run the same code; if a P4 is an "actual Intel chip" an Athlon64
>>>is an "actual AMD chip". No it's not something else and the ownership of
>>>the definition has just formally changed... to shared?
>>>
>>It's your claim, George. You can't demand that I do the work to back
>>up your claim, can you? In any case, I'm not going to. Google says
>>that the word "incompatible" belongs to you.
>
>4bv89155v8hviq15hg3kv810ru1gos26q2@4ax.com - "An AMD processor is
>incompatible with an Intel processor because...." seems to predate anything
>I've said.
>
Sorry, I couldn't find that. As it is, though, anything less than the
full quote is misleading:

"An AMD processor is incompatible with an Intel processor because it
doesn't say Intel on the package and Intel will tell you to pound sand
if you have questions about it."

It's clear that I'm not claiming they are incompatible in any ordinary
sense. Even so, it is just inconceivable to me that you'll never turn
up differences between the two processors that mean that a user
application will work with one and not the other. Badly designed
application? Probably. It's just something that people aren't going
to worry about it if they don't have to.

>>>I've no idea what that is supposed to mean nor what mission you have in
>>>mind. You can't possibly argue with the fact that the Athlon64/Opteron
>>>works... rather well in fact. Whether you've personally tried/tested one
>>>has nothing to do with the facts. Hell even Intel's new CEO has resorted
>>>to the "don't worry chaps, we'll catch them up [... in about 18 months]"...
>>>funny that: AMD is going to stand still to give them a fair whack at
>>>it.:-[]
>>
>>What has *any* of that got to do with the fact that most people are
>>going to test for mission-critical applications?
>
>Like I said, the AMD CPU works... at least as well as any Intel version; in
>fact an examination of specified operating parameters and current empirical
>evidence indicates that the Intel product is subject to higher thermal
>stresses... certainly something to be taken into account. Mission
>critical, however, would cover many other more likely failure points in a
>system infrastructure than the CPU. I'd expect that there are even some
>who would rule out any x86 system for that task. You'll have to give
>evidence: of actual failure, or why an AMD system would be more
>susceptible.

You're implying I'm saying things that I'm not saying. People are
going to test for mission-critical applications for whatever processor
they use, and because it works with one doesn't mean they will forgo
testing with another. As I hear it, more and more mission-critical
stuff goes on x86.

As to vulnerability, I wouldn't know how to judge one over the other,
and I never made any claims (at least for this generation of
processor).

<snip>

>
>>>>That buyers are biased toward products with more market share seems so
>>>>self-evident in this case, that I don't know why we're discussing it.
>>>>AMD has the better product. It should sweep the market. It isn't. It
>>>>won't. Same could be said for GM cars for decades (although they sure
>>>>have taken a beating).
>>>
>>>To say "it won't" (ever) is absurd... though sweep is obviously not
>>>practical given current production. GM is not really a good analogy --
>>>Delphi, Valeo or Nippon-Denso would be better -- but I'm sure you haven't
>>>missed the fact that Toyota & Honda started small and now own the
>>>automobile market - it took a bit of time to ramp to that level... and even
>>>the sheep followed. GM makes trucks for a living.
>>>
>>"It won't" in this instance is ambiguous. Could the entire
>>infrastructure of the semiconductor industry change? Sure. It's
>>happened in lots of industries. It takes time. Short of that
>>happening, there should be a shortage of AMD chips. I don't see that
>>heppening, either. This really does remind me of sports talk radio.
>
>You obviously haven't tried to buy an AMD CPU recently - "shortage" is only
>a relative term here but there is obvious binning which is causing
>shortages in some of the more popular mid-priced Athlon64s... probably good
>for AMD's ASP.
>
So AMD has got its pricing model wrong becaue they didn't predict
yields correctly.

>>>You just won't give up with this "advantage" of volume... reminds me of
>>>Lenin's famous quote: "quantity has a quality all of its own".🙂 Nope,
>>>the only advantage here is performance/$ and your, again repetitious,
>>>insistence on "problems that might show up" is ludicrous in the face of
>>>proven facts. What problems?... enumerate please... or give it up!... even
>>>better: buy an Athlon64 and tell us what you find wrong with it. Your
>>>misplaced suspicion is ugly, well past due date and not at all creditable.
>>>
>>What, now you're smearing me with "commie" labels? Are you _sure_
>>you've never worked in advertising, marketing, public relations,
>>fundraising, or some other manipulative business?
>
>Whoever the quote is due to matters not - would Napoleon make you feel
>better?🙂 Feigned indignation is no substitute for facts.
>
I wouldn't have bristled. As to facts, the use of a quote attached to
a controversial historical figure isn't one. It's a rhetorical tactic
and not an especially attractive one.

You're trying to get me to make claims about the relative quality of
the products. I think I'm just making a statement about how buyers
think and about how markets work. Purchasing from the dominant
supplier is always safer, and the rules of the business more or less
guarantee that Intel is going to be the dominant supplier for the
forseeable future.

As it is, you are trying to make arguments both ways: that AMD has a
chip shortage (indicates that demand exceeds supply) and that AMD is a
safe supplier even though it's number 2. Both can't be true. As it
is, chips can be bought from a safe commodity supplier who can deliver
them in nearly unlimited quantities and doesn't have to worry all that
much about hitting production targets accurately (the worst they have
to worry about is articles in the WSJ about growing inventory). It
isn't just a mattr of buyer irrationality. Buyers want to know that
they can get what they want when they need it. The safest bet to be
able to do that is the biggest supplier. A company like Sun that is
building a future around AMD chips is inevitably adding risk to its
bottom line by doing do. You don't like it, apparently, but that's
the way life goes.

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

On Thu, 12 May 2005 10:22:19 -0400, Jason Gurtz wrote:

> On 5/12/2005 09:53, Del Cecchi wrote:
>
>> 64 bit Linux has been available for some time. Now maybe perhaps the
>> compilers could be claimed to not be up to snuff for the weirdness that is
>> Itanium, but that is pretty weak. What's your next excuse?
>
> Sure, 64-bit Osen have been available for a bit. But, how many 64-bit
> applications--designed for 64-bit--are you running?

All the applications I run are 64bit. "Designed", well that's a stretch
of an argument.

> Yea, then there's the compiler problem...

Problem?


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

"Del Cecchi" <dcecchi.nospam@att.net> writes:
>
> Lenin, Stalin, Mao. What difference does it make which insane genocidal
> murderous dictator said it? It isn't true any more than most of the
> things they said.

Just in that you should strive for accuracy, including ascribing the
correct quote to the correct insane genocidal murderous dictator.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 30 May 2005 07:20:37 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Mon, 30 May 2005 02:02:14 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>On Sun, 29 May 2005 07:06:28 -0400, Robert Myers <rmyers1400@comcast.net>
>>wrote:
>>
>>>On Sun, 29 May 2005 01:49:25 -0400, George Macdonald
>>><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>>>
>><<snip>>
>>
>>>>Look back in the thread for *your* use and definition of "incompatible" -
>>>>no it wasn't I who started this. Both AMD & Intel sell actual x86 chips
>>>>which both run the same code; if a P4 is an "actual Intel chip" an Athlon64
>>>>is an "actual AMD chip". No it's not something else and the ownership of
>>>>the definition has just formally changed... to shared?
>>>>
>>>It's your claim, George. You can't demand that I do the work to back
>>>up your claim, can you? In any case, I'm not going to. Google says
>>>that the word "incompatible" belongs to you.
>>
>>4bv89155v8hviq15hg3kv810ru1gos26q2@4ax.com - "An AMD processor is
>>incompatible with an Intel processor because...." seems to predate anything
>>I've said.
>>
>Sorry, I couldn't find that. As it is, though, anything less than the
>full quote is misleading:
>
>"An AMD processor is incompatible with an Intel processor because it
>doesn't say Intel on the package and Intel will tell you to pound sand
>if you have questions about it."

D'oh! You can't find that then you find it - what the hell are you on
about? What is it that you can't find about a Message ID? If your
newsreader doesn't support it, plug it into the Message ID box at Google
Groups.

>It's clear that I'm not claiming they are incompatible in any ordinary
>sense.

Just what are we to make of this? You said it... but you didn't
really<gawp> - on top of which you ascribed the use to me. Nobody in their
right mind would expect Intel to help them with an AMD CPU... and yet
that's a reason to mark AMD's product as "incompatible". This is nuts - an
exercise in the absurd.

> Even so, it is just inconceivable to me that you'll never turn
>up differences between the two processors that mean that a user
>application will work with one and not the other. Badly designed
>application? Probably. It's just something that people aren't going
>to worry about it if they don't have to.

What utter rubbish - there's as much chance of finding an app which works
with only one version of a P4 and not the other versions... or a P-M or
vice versa. Again you have no evidence so you speculate about things which
might be... and with apparently no first-hand knowledge or experience.
Talk about a definition of FFUD [sic]!

>>>>I've no idea what that is supposed to mean nor what mission you have in
>>>>mind. You can't possibly argue with the fact that the Athlon64/Opteron
>>>>works... rather well in fact. Whether you've personally tried/tested one
>>>>has nothing to do with the facts. Hell even Intel's new CEO has resorted
>>>>to the "don't worry chaps, we'll catch them up [... in about 18 months]"...
>>>>funny that: AMD is going to stand still to give them a fair whack at
>>>>it.:-[]
>>>
>>>What has *any* of that got to do with the fact that most people are
>>>going to test for mission-critical applications?
>>
>>Like I said, the AMD CPU works... at least as well as any Intel version; in
>>fact an examination of specified operating parameters and current empirical
>>evidence indicates that the Intel product is subject to higher thermal
>>stresses... certainly something to be taken into account. Mission
>>critical, however, would cover many other more likely failure points in a
>>system infrastructure than the CPU. I'd expect that there are even some
>>who would rule out any x86 system for that task. You'll have to give
>>evidence: of actual failure, or why an AMD system would be more
>>susceptible.
>
>You're implying I'm saying things that I'm not saying.

Like what? I don't think there's any doubt that you've questioned the
viability of the AMD CPUs vs. Intel's.

> People are
>going to test for mission-critical applications for whatever processor
>they use, and because it works with one doesn't mean they will forgo
>testing with another. As I hear it, more and more mission-critical
>stuff goes on x86.

As I hear it, "people" in IT rarely do their own testing. All the big OS
vendors and ISVs, SAP, Oracle, IBM, etc. have run their software on both
CPUs. There are thousands of benchmarks published on the Web using
commercial software - differences between PIII, P-M, P4(flavors), AthlonXP,
Athlon64 are well understood. For home-baked stuff you run it just to be
sure it works - "testing" reqts. are minimal for an IT organization.

>As to vulnerability, I wouldn't know how to judge one over the other,
>and I never made any claims (at least for this generation of
>processor).

Your "claims" are well documented.

><snip>

>>>"It won't" in this instance is ambiguous. Could the entire
>>>infrastructure of the semiconductor industry change? Sure. It's
>>>happened in lots of industries. It takes time. Short of that
>>>happening, there should be a shortage of AMD chips. I don't see that
>>>heppening, either. This really does remind me of sports talk radio.
>>
>>You obviously haven't tried to buy an AMD CPU recently - "shortage" is only
>>a relative term here but there is obvious binning which is causing
>>shortages in some of the more popular mid-priced Athlon64s... probably good
>>for AMD's ASP.
>>
>So AMD has got its pricing model wrong becaue they didn't predict
>yields correctly.

I dunno how to explain this to you but it's not a static model and demand
is always kinda difficult to predict - ask Intel about that... and their
umm, fairly recent inventory problems.🙂 There's also the fact that, as
one would expect, the channel plays games with the prices. Bottom line is
that AMD CPU prices are holding quite well., which some buyers may find
annoying; OTOH it means that they don't feel cheated by precipitous drops
in price a few weeks after purchase.

>>Whoever the quote is due to matters not - would Napoleon make you feel
>>better?🙂 Feigned indignation is no substitute for facts.
>>
>I wouldn't have bristled. As to facts, the use of a quote attached to
>a controversial historical figure isn't one. It's a rhetorical tactic
>and not an especially attractive one.

Lenin, Stalin, Napoleon? Since the target was not your idealogical
"appearance", I'm afraid I see no reason for your complaint.

>You're trying to get me to make claims about the relative quality of
>the products. I think I'm just making a statement about how buyers
>think and about how markets work. Purchasing from the dominant
>supplier is always safer, and the rules of the business more or less
>guarantee that Intel is going to be the dominant supplier for the
>forseeable future.

Fer Chrissakes give it up.

>As it is, you are trying to make arguments both ways: that AMD has a
>chip shortage (indicates that demand exceeds supply) and that AMD is a
>safe supplier even though it's number 2. Both can't be true.

There's more than one market to be err, supplied. It gets
complicated.<shrug>

> As it
>is, chips can be bought from a safe commodity supplier who can deliver
>them in nearly unlimited quantities and doesn't have to worry all that
>much about hitting production targets accurately (the worst they have
>to worry about is articles in the WSJ about growing inventory). It
>isn't just a mattr of buyer irrationality. Buyers want to know that
>they can get what they want when they need it. The safest bet to be
>able to do that is the biggest supplier. A company like Sun that is
>building a future around AMD chips is inevitably adding risk to its
>bottom line by doing do. You don't like it, apparently, but that's
>the way life goes.

Over-simplification. Extreme point analysis is not applicable here.

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

George Macdonald wrote:
> On Mon, 30 May 2005 07:20:37 -0400, Robert Myers <rmyers1400@comcast.net>
> wrote:
>
> >On Mon, 30 May 2005 02:02:14 -0400, George Macdonald
> ><fammacd=!SPAM^nothanks@tellurian.com> wrote:
> >
> >>On Sun, 29 May 2005 07:06:28 -0400, Robert Myers <rmyers1400@comcast.net>
> >>wrote:
> >>
> >>>On Sun, 29 May 2005 01:49:25 -0400, George Macdonald
> >>><fammacd=!SPAM^nothanks@tellurian.com> wrote:
> >>>
> >><<snip>>
> >>
> >>>>Look back in the thread for *your* use and definition of "incompatible" -
> >>>>no it wasn't I who started this. Both AMD & Intel sell actual x86 chips
> >>>>which both run the same code; if a P4 is an "actual Intel chip" an Athlon64
> >>>>is an "actual AMD chip". No it's not something else and the ownership of
> >>>>the definition has just formally changed... to shared?
> >>>>
> >>>It's your claim, George. You can't demand that I do the work to back
> >>>up your claim, can you? In any case, I'm not going to. Google says
> >>>that the word "incompatible" belongs to you.
> >>
> >>4bv89155v8hviq15hg3kv810ru1gos26q2@4ax.com - "An AMD processor is
> >>incompatible with an Intel processor because...." seems to predate anything
> >>I've said.
> >>
> >Sorry, I couldn't find that. As it is, though, anything less than the
> >full quote is misleading:
> >
> >"An AMD processor is incompatible with an Intel processor because it
> >doesn't say Intel on the package and Intel will tell you to pound sand
> >if you have questions about it."
>
> D'oh! You can't find that then you find it - what the hell are you on
> about? What is it that you can't find about a Message ID? If your
> newsreader doesn't support it, plug it into the Message ID box at Google
> Groups.
>

It isn't absolutely obvious that I found the quote from the message ID
because I quoted said message in my reply?

> >It's clear that I'm not claiming they are incompatible in any ordinary
> >sense.
>
> Just what are we to make of this? You said it... but you didn't
> really<gawp> - on top of which you ascribed the use to me. Nobody in their
> right mind would expect Intel to help them with an AMD CPU... and yet
> that's a reason to mark AMD's product as "incompatible". This is nuts - an
> exercise in the absurd.
>
Are you angling for a position on Firing Line?

> > Even so, it is just inconceivable to me that you'll never turn
> >up differences between the two processors that mean that a user
> >application will work with one and not the other. Badly designed
> >application? Probably. It's just something that people aren't going
> >to worry about it if they don't have to.
>
> What utter rubbish - there's as much chance of finding an app which works
> with only one version of a P4 and not the other versions... or a P-M or
> vice versa. Again you have no evidence so you speculate about things which
> might be... and with apparently no first-hand knowledge or experience.
> Talk about a definition of FFUD [sic]!
>

George, this is really very easy. In your view of the world, AMD
processors are going to dominate the market. In my view of the world,
that isn't going to happen anytime soon. Since AMD, at the moment, is
the better deal for almost everyone, there has to be a reason why, in
my view of the world, Intel's dominance will continue. I've stated my
view of the world as clearly as I know how. Buyers favor the dominant
supplier for a whole host of reasons, not all of them peculiar to IT.
The reasons may look irrational, and some of them are irrational, but
the safest bet is to buy from the largest, most stable supplier. The
largest, most stable supplier is Intel. That's true now and far into
the forseeable future. I'm tired of arguing about it.

RM