Intel concedes server business to AMD ;-)

Page 4 - 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 31 May 2005 09:12:51 -0700, rbmyersusa@gmail.com wrote:

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

Have you been studying law?🙂

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

I'm that good?:-[]

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

No - you have it wrong. I do not expect AMD to dominate the market - I
just think they have an even chance of success; ideally from my consumer
POV, there'd be a 50:50 market split just to be sure that neither loses it
completely. Personally I buy the best deal for the $ with possibly a
narrow advantage to the underdog to contribute my bit to the 50:50; others
may see it differently.<shrug>

Apart from the smear aspects of your attacks on AMD, I dispute your
authority to speak for "buyers" in general. There are clearly sectors of
the market, outside the dumping activity, who choose based on performance.
I also am tired of arguing but I will not hesitate to present my view on
the subject again, when provoked.

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

On Tue, 31 May 2005 18:14:54 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:


>Apart from the smear aspects of your attacks on AMD,

Smear is an ugly word. I just don't have the emotional stake in this
you seem to think I do. Why are you using such emotionally-charged
language?

>I dispute your authority to speak for "buyers" in general.

I don't have authority to speak for anyone but myself. All I can do
is to observe. Whether I observe accurately or not has nothing to do
with authority.

> There are clearly sectors of
>the market, outside the dumping activity, who choose based on performance.

Well, of course there are.

>I also am tired of arguing but I will not hesitate to present my view on
>the subject again, when provoked.

I certainly hope you will. I've enjoyed most of our exchanges. It's
just that we usually find something more substantive to argue about.

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

On Tue, 31 May 2005 20:52:50 -0400, Robert Myers <rmyers1400@comcast.net>
wrote:

>On Tue, 31 May 2005 18:14:54 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>
>>Apart from the smear aspects of your attacks on AMD,
>
>Smear is an ugly word. I just don't have the emotional stake in this
>you seem to think I do. Why are you using such emotionally-charged
>language?

You used "smear" for what to me seemed a relatively innocuous
comparison.<shrug>

>>I dispute your authority to speak for "buyers" in general.
>
>I don't have authority to speak for anyone but myself. All I can do
>is to observe. Whether I observe accurately or not has nothing to do
>with authority.

OK, so we have agreed to disagree then.

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

keith wrote:
> 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.

More to the point, do any of your applications actually benefit from 64
bit? Outside of the raw performance of the CPU, do you have something
which benefits from the big address space?

Web, news, mail, and DNS servers tend to be many small processes (or
threads) which have a small address space. They run out of i/o before
anything else.
>
>
>>Yea, then there's the compiler problem...
>
>
> Problem?

Depending on your CPU and o/s, problem. 64 bit compilers are nowhere
near able to extract the best performance from a CPU in many cases.

--
bill davidsen (davidsen@darkstar.prodigy.com)
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com
 
Archived from groups: comp.sys.intel,comp.sys.ibm.pc.hardware.chips (More info?)

"Bill Davidsen" <davidsen@darkstar.prodigy.com> wrote in message
news:RuMne.10330$4u.4702@newssvr33.news.prodigy.com...

> More to the point, do any of your applications actually benefit from 64
> bit? Outside of the raw performance of the CPU, do you have something
> which benefits from the big address space?

The question is what will people come out with once most of the market
is 64-bit capable? Will they bother to continue to support 32-bits if they
most of the market doesn't need it and there's benefits to using 64-bit
capabilities?

How much 16-bit software is available today? Why? It's not hard to
recompile your code for 16-bits and surely having some more market is better
than not.

A big issue is support and diminishing returns. Why can't you get as
many commercial applications for Irix as for Linux? It's probably just a
little more than a recompile. The point is, another platform means more
testing and more support issues.

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

Bill Davidsen wrote:
> keith wrote:
>
>>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.
>
>
> More to the point, do any of your applications actually benefit from 64
> bit? Outside of the raw performance of the CPU, do you have something
> which benefits from the big address space?
>
> Web, news, mail, and DNS servers tend to be many small processes (or
> threads) which have a small address space. They run out of i/o before
> anything else.

Sigh. Yet another who thinks that addressing more RAM is all
there is to AMD64.

For many apps, the primary benefits of AMD64 are
1.) Twice as many registers
2.) The non-SSE registers have doubled from 32 bits wide to 64.

A *lot* of apps can benefit from more and wider registers.

>
>>
>>>Yea, then there's the compiler problem...
>>
>>
>>Problem?
>
>
> Depending on your CPU and o/s, problem. 64 bit compilers are nowhere
> near able to extract the best performance from a CPU in many cases.
>
 
Archived from groups: comp.sys.intel,comp.sys.ibm.pc.hardware.chips (More info?)

Rob Stow wrote:

> Bill Davidsen wrote:
>> keith wrote:
>>
>>>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.
>>
>>
>> More to the point, do any of your applications actually benefit from 64
>> bit? Outside of the raw performance of the CPU, do you have something
>> which benefits from the big address space?
>>
>> Web, news, mail, and DNS servers tend to be many small processes (or
>> threads) which have a small address space. They run out of i/o before
>> anything else.
>
> Sigh. Yet another who thinks that addressing more RAM is all
> there is to AMD64.
>
> For many apps, the primary benefits of AMD64 are
> 1.) Twice as many registers
> 2.) The non-SSE registers have doubled from 32 bits wide to 64.
>
> A *lot* of apps can benefit from more and wider registers.

There are also some other benefits: consider a case where your dealing with
software oriented towards HDD's, the largest size you can use in a register
with ia32 is 32 bits hence 4 gig. Sure there's a 64 bit type but its a
structure of 2 32 bit vars, with x86_64 now that can go away and integral
64 bit vars can be used.
Integer Math can be done in 2 registers instead of 4 for operations
resulting in greater than 32 bits.
How about holding/passing an IPv6 address?
It seems the longer you think about it the more you can come up with, it
just takes some thought.

Eric