Intel concedes server business to AMD ;-)

[keith]

If you got the money, Keith, IBM got the time (and, in most cases, the
archival material).


Because you are so obsessed with the performance of hardware, you
assume that everyone else is, too. They're not. The software is more
important than the hardware, the people who run the software are more
important than the software, and the business processes they support
are more important than they are. An AMD processor is not an Intel
processor. Period. "Compatible" is a sucker word.

Oh wow! You really are stretching now! The only *possible* difference is
if software is tuned to one particular processor or another (not a good
idea, given that Inel can't even keep these things straight). This is a
*performance* issue, not in any way compatibility.

Me thinks you've lost it Robert!

 

[keith]

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]

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!

 

[Robert Myers]

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

 

[Robert Myers]

Oh wow! You really are stretching now! The only *possible* difference is
if software is tuned to one particular processor or another (not a good
idea, given that Inel can't even keep these things straight). This is a
*performance* issue, not in any way compatibility.

Me thinks you've lost it Robert!

That's a possibility, but it's not related to my bringing up
performance in this post. From your point of view, as I infer it, you
cannot understand why anyone would buy an Intel processor when you
could get better performance from an AMD processor for the same or
less money. My point is that, to most people, performance is well
down on the list of priorities. The differences are not enough to
drive a decision.

RM

 

[Robert Myers]

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

 

[Keith R. Williams]

That's a possibility, but it's not related to my bringing up
performance in this post. From your point of view, as I infer it, you
cannot understand why anyone would buy an Intel processor when you
could get better performance from an AMD processor for the same or
less money. My point is that, to most people, performance is well
down on the list of priorities. The differences are not enough to
drive a decision.

If performance isn't important, who cares if the code is optimized at
all. Who cares what processor is used. Buy a Via and make a tree-
hugger happy.

No, I don't see any point in buying a P4. Your "compatibility" argument
is a canard.

 

[Robert Myers]

If performance isn't important, who cares if the code is optimized at
all. Who cares what processor is used. Buy a Via and make a tree-
hugger happy.

As we both know, energy efficiency may well be enough to drive
purchasing decisions at some point, but, when that happens, it won't
likely be Via that captures the sales.

No, I don't see any point in buying a P4. Your "compatibility" argument
is a canard.

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.

In the end, Keith, markets make the rules, individuals don't.

RM

 

[George Macdonald]

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.

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!

 

[George Macdonald]

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!

 

[Robert Myers]

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

 

[Robert Myers]

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.

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.

Some people are always late to the game!

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

RM

 

[keith]

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]

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]

As we both know, energy efficiency may well be enough to drive
purchasing decisions at some point, but, when that happens, it won't
likely be Via that captures the sales.

I think you really need _Hooked_on_Phonics_, Robert.

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.

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.

 

[Stephen Lee -- post replies please]

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

 

[George Macdonald]

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.

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?

 

[George Macdonald]

You surely know that I know that history.

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

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.

Avis did good with their "We're No. 2" campaign, but they're still No.
2.

Hmm, Intel's future??

 

[Robert Myers]

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.

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?

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.


Hmm, Intel's future??

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

RM

 

[Robert Myers]

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


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.

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