Sign in with
Sign up | Sign in
Your question

Intel concedes server business to AMD ;-)

Last response: in CPUs
Share
Anonymous
a b à CPUs
May 10, 2005 12:15:27 AM

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

The actual title of the article is "Intel playing catch-up to AMD
business"

http://www.networkworld.com/news/2005/050905-intel-amd....

<quote>

Intel's top server executive recently acknowledged the disparity
between his company's server processor road maps and Advanced Micro
Devices, but said Intel plans to close the gap soon with a revitalized
product line.

<snip>

Users will find dual-core Opteron servers intriguing when compared
with single-core Xeon servers, Gelsinger says. "There will clearly be
some tire-kickers, and maybe some losses," he says, referring to Intel
customers who might switch to servers based on AMD's chips.

However, enterprise customers are generally conservative when it comes
to technology changes, Gelsinger says. Users interested in servers
with four or more processors currently have the option of Intel's new
Truland platform, which will protect any current investments by
letting customers plug dual-core Xeon chips into their current Truland
servers when these chips become available next year, he says.

</quote>

"Itanium" nowhere to be found in the article.

RM
Anonymous
a b à CPUs
May 10, 2005 6:12:21 AM

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

Robert Myers wrote:

>
> "Itanium" nowhere to be found in the article.
>
> RM

How about in Intel's own resource centre? Looks like Intel is still
trying to push Itanium over Xeon at every opportunity.

64-bit Server Resource Center and 64-bit Demo for Processors
http://developer.intel.com/business/bss/products/server...

Yousuf Khan
Anonymous
a b à CPUs
May 10, 2005 3:16:41 PM

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

On 5/9/2005 20:15, Robert Myers wrote:
> The actual title of the article is "Intel playing catch-up to AMD
> business"

Well, we can only hope for this sooner, rather than later:
<http://www.theinquirer.net/?article=23055&gt;

I've found it especially intriguing that Supermicro now offers AMD based
products.

~Jason

--

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Related resources
Anonymous
a b à CPUs
May 10, 2005 3:40:27 PM

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

On Tue, 10 May 2005 11:16:41 -0400, Jason Gurtz <no@noemail.com>
wrote:

>On 5/9/2005 20:15, Robert Myers wrote:
>> The actual title of the article is "Intel playing catch-up to AMD
>> business"
>
>Well, we can only hope for this sooner, rather than later:
><http://www.theinquirer.net/?article=23055&gt;
>
Time to take out earthquake insurance. An Intel interview with very
little handwaving and an Inquirer article that offers a positive take
on upcoming Intel offerings.

>I've found it especially intriguing that Supermicro now offers AMD based
>products.
>

Facilitated, I am sure, by Intel's "we don't need you" attitude.

RM
Anonymous
a b à CPUs
May 10, 2005 3:46:58 PM

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

On Tue, 10 May 2005 02:12:21 -0400, Yousuf Khan <bbbl67@ezrs.com>
wrote:

>Robert Myers wrote:
>
>>
>> "Itanium" nowhere to be found in the article.
>>
>
>How about in Intel's own resource centre? Looks like Intel is still
>trying to push Itanium over Xeon at every opportunity.
>
>64-bit Server Resource Center and 64-bit Demo for Processors
>http://developer.intel.com/business/bss/products/server...
>

I don't see any sign of Intel backing away from Itanium. I was just
noticing an astonishing lack of Wizard of Ozry.

RM
Anonymous
a b à CPUs
May 11, 2005 5:05:19 PM

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

Robert Myers wrote:
> The actual title of the article is "Intel playing catch-up to AMD
> business"
>
> http://www.networkworld.com/news/2005/050905-intel-amd....

Tom's Hardware Guide Processors: AMD's Dual Core Athlon 64 X2 Strikes
Hard - Here Comes The King: Athlon 64 X2 Reviewed
http://www.tomshardware.com/cpu/20050509/index.html

AMD's new dual-core CPUs trounce Intel's - CNET.com
http://www.cnet.com/4520-6022_1-6217968-1.html?tag=prmo...

And here's Intel's response:

» Intel on AMD's early dual-core wins: "Not so fast" | Between
the Lines | ZDNet.com
http://blogs.zdnet.com/BTL/index.php?p=1356

Yousuf Khan
Anonymous
a b à CPUs
May 12, 2005 1:08:34 AM

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

On 11 May 2005 13:05:19 -0700, "Yousuf Khan" <yjkhan@gmail.com>
wrote:

>Robert Myers wrote:
>> The actual title of the article is "Intel playing catch-up to AMD
>> business"
>>
>> http://www.networkworld.com/news/2005/050905-intel-amd....
>
>Tom's Hardware Guide Processors: AMD's Dual Core Athlon 64 X2 Strikes
>Hard - Here Comes The King: Athlon 64 X2 Reviewed
>http://www.tomshardware.com/cpu/20050509/index.html
>
>AMD's new dual-core CPUs trounce Intel's - CNET.com
>http://www.cnet.com/4520-6022_1-6217968-1.html?tag=prmo...
>
>And here's Intel's response:
>
>» Intel on AMD's early dual-core wins: "Not so fast" | Between
>the Lines | ZDNet.com
>http://blogs.zdnet.com/BTL/index.php?p=1356

Wow.. that's an extraordinarily WEAK response by Intel.

"AMD's integrated memory controller is bad because a year from now
OEMs will have to requalify their systems for DDR2 memory"?

Intel better hope that they've got a better answer than that!

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
May 12, 2005 12:27:32 PM

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

On Wed, 11 May 2005 21:08:34 -0400, Tony Hill
<hilla_nospam_20@yahoo.ca> wrote:

>
>Wow.. that's an extraordinarily WEAK response by Intel.
>
>"AMD's integrated memory controller is bad because a year from now
>OEMs will have to requalify their systems for DDR2 memory"?
>
>Intel better hope that they've got a better answer than that!
>

I'd say it's a fairly shrewd response, and it's more than what you
quoted:

1. AMD has made a short-sighted decision by sticking with DDR when
DDR2 is the longer term solution. Your response: buyers don't or
shouldn't care, because all the hassle will be someone else's problem.
My only quibble with Intel's response would be that they didn't
_quite_ close the loop by saying: you remember how hard it's been
sometimes to get platforms for AMD processors you could really count
on? Each time you change memory technology, you have to start over.
FUD? Of course. This is marketing.

2. AMD processors don't have hyperthreading. Hyperthreading is
already in the benchmarks? Well, yes, but one of these days, they're
going to figure out how really to take advantage of HT. Honest.
Meanwhilst, the manager stuck with Intel processors that are
outperformed in benchmarks can say, "Yeah, but because of
hyperthreading, this is really like an 8-way box."

3. AMD doesn't have the capacity to be Intel. That's the one that
really counts for managers with their thinking caps on.

RM
Anonymous
a b à CPUs
May 12, 2005 12:34:12 PM

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

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

How is that weak? It's a well known fact that not having a good tool
chain can be a serious issue. I mean, let's be honest, when MIPS,
POWERPC, SPARC etc. debuted, it was pretty darn obvious that their
compilers were far less mature than those for S/360; don't you think
that made adoption of those architectures a little hard to swallow for
those used to S/360's development tools?

> It still isn't clear that the Itanium architecture was a good idea,
or
> whether it was Intel's PS/2.

Agreed...it will take time to tell.

David
Anonymous
a b à CPUs
May 12, 2005 1:56:25 PM

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

Robert Myers wrote:
> 2. AMD processors don't have hyperthreading. Hyperthreading is
> already in the benchmarks? Well, yes, but one of these days, they're
> going to figure out how really to take advantage of HT. Honest.
> Meanwhilst, the manager stuck with Intel processors that are
> outperformed in benchmarks can say, "Yeah, but because of
> hyperthreading, this is really like an 8-way box."

Well, I just posted a story talking about how the Netburst architecture
is likely going to disappear by 2006. Without Netburst's long
pipelines, Hyperthreading becomes difficult with the short-pipeline
architecture that's going to replace it. But Intel is going to try it
anyways.

> 3. AMD doesn't have the capacity to be Intel. That's the one that
> really counts for managers with their thinking caps on.

For servers, AMD has the capacity right now to supply server chips for
the entire market including the non-x86 server market. Of course,
people in the non-x86 market aren't going to be able to switch that
simply.

Yousuf Khan
Anonymous
a b à CPUs
May 12, 2005 2:14:18 PM

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

Robert Myers wrote:
> Should be posting to comp.arch so I could get major flames.

Oh please, copy the thread over there if you like, but don't crosspost
it there! That way we don't have to deal with comp.arch regulars over
here.

Yousuf Khan
Anonymous
a b à CPUs
May 12, 2005 2:22:19 PM

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

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?

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

~Jason

--

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Anonymous
a b à CPUs
May 12, 2005 3:06:32 PM

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

Jason Gurtz wrote:
> Sure, 64-bit Osen have been available for a bit. But, how many
64-bit
> applications--designed for 64-bit--are you running?
>
> Yea, then there's the compiler problem...

If the OS is Linux, then probably all of the applications are already
64-bit, whether they needed to be or not. It's simply a matter of
recompiling under Linux. A bit more difficult under Windows.

The Windows experience is going to be much more interesting to watch.
This is really what x64 was designed to address -- the ability to
seamlessly run 32-bit apps under 64-bit OSes. In the closed Windows
world, recompiling isn't all that simple, so the chip has to take the
responsibility to handle a variety of code bases.

And Microsoft hasn't made life easier on itself by not supporting
32-bit drivers alongside 32-bit apps. That means the class of software
that is the most tricky to create and maintain (i.e. device drivers) is
the one class of software that definitely has to be recompiled in order
to even work in the 64-bit OS.

Yousuf Khan
Anonymous
a b à CPUs
May 12, 2005 3:07:14 PM

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

"David Kanter" <dkanter@gmail.com> wrote in message
news:1115912052.590234.270860@g14g2000cwa.googlegroups.com...
>> 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?
>
> How is that weak? It's a well known fact that not having a good tool
> chain can be a serious issue. I mean, let's be honest, when MIPS,
> POWERPC, SPARC etc. debuted, it was pretty darn obvious that their
> compilers were far less mature than those for S/360; don't you think
> that made adoption of those architectures a little hard to swallow for
> those used to S/360's development tools?
>
>> It still isn't clear that the Itanium architecture was a good idea,
> or
>> whether it was Intel's PS/2.
>
> Agreed...it will take time to tell.
>
> David
>
It's weak because they have had what, 4 or 5 years to get some compilers out
there that work. If they haven't yet succeeded in doing so either it is
much harder than other architectures, lending credence to the idea that
Itanium was a bad idea or Intel is not trying very hard to make it happen,
lending credence to the idea that they are inept.

I know that there is not much demand for Itanium stuff, but some cash from
HP and Intel and some contibutions to GCC or whatever would go a long way in
enhancing the offerings.

del cecchi
Anonymous
a b à CPUs
May 12, 2005 4:46:19 PM

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

On Thu, 12 May 2005 11:07:14 -0500, "Del Cecchi"
<dcecchi.nospam@att.net> wrote:

>
>"David Kanter" <dkanter@gmail.com> wrote in message
>news:1115912052.590234.270860@g14g2000cwa.googlegroups.com...
>>> 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?
>>
>> How is that weak? It's a well known fact that not having a good tool
>> chain can be a serious issue. I mean, let's be honest, when MIPS,
>> POWERPC, SPARC etc. debuted, it was pretty darn obvious that their
>> compilers were far less mature than those for S/360; don't you think
>> that made adoption of those architectures a little hard to swallow for
>> those used to S/360's development tools?
>>
>>> It still isn't clear that the Itanium architecture was a good idea,
>> or
>>> whether it was Intel's PS/2.
>>
>> Agreed...it will take time to tell.
>>
>>
>It's weak because they have had what, 4 or 5 years to get some compilers out
>there that work. If they haven't yet succeeded in doing so either it is
>much harder than other architectures, lending credence to the idea that
>Itanium was a bad idea or Intel is not trying very hard to make it happen,
>lending credence to the idea that they are inept.
>
Almost anybody would have to vote for inept at this point wouldn't
they? Were I professer at the Harvard Business School, I'd probably
be looking around for some smart young whip to write a thesis on how
this always happens to technology companies, with Intel (and
Microsoft, btw) as only the latest case studies.

A software type (take it easy, Keith, he worked for a do-it-all chip
company that I'll bet you've worked with, but no names) opined to me
recently that AMD's advantage is that they really have no choice but
to get outside help, so they get it. My interpolation is that, given
the state of the industry, the best is generally available for hire by
AMD unless they happen to work for Intel.

I'd love to be able to go back and look at the historical documents at
Intel. What did they know and when did they know it? Even knowing
what they _thought_ they knew would make a fascinating read.

It isn't so much that they didn't get it right in four or five
years...the problem is that hard. It's hard to comprehend what they
were doing in terms of risk management, though. Not much, apparently.

>I know that there is not much demand for Itanium stuff, but some cash from
>HP and Intel and some contibutions to GCC or whatever would go a long way in
>enhancing the offerings.
>
There was recently a Gelato meeting dealing with getting some serious
help for gcc with Itanium. I haven't followed the details since the
meeting to see whether anything really happened.

I'll venture that no compiler solution to Itanium's problems is
forthcoming. Not that significant progress isn't possible. It just
won't be enough.

That means death for Itanium? I'm less sure of that. It depends on
how adventurous Intel is willing to be. The fact that execution pipes
stall frequently really shouldn't be a serious problem for server
applications. The idea that you have to keep a single pipe stuffed
full and running all the time is mainframe and HPC thinking.

The only thing Intel really has to preserve is the ISA. If you can
add more execution paths without blowing the power consumption through
the roof, you should be able to make practically any architecture get
any kind of throughput you want as a multi-threaded server.

....That's the path (lots of threads, who cares if they stall) I
thought Intel was going to take with the core that I gather was being
designed at Marlborough. That core, apparently, is dead, so who knows
what Intel is going to do.

Should be posting to comp.arch so I could get major flames.

RM
Anonymous
a b à CPUs
May 12, 2005 6:58:15 PM

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

On 12 May 2005 10:14:18 -0700, "YKhan" <yjkhan@gmail.com> wrote:

>Robert Myers wrote:
>> Should be posting to comp.arch so I could get major flames.
>
>Oh please, copy the thread over there if you like, but don't crosspost
>it there! That way we don't have to deal with comp.arch regulars over
>here.
>
It was a joke, Yousuf.

Some of the participants here are well-respected comp.arch regulars in
any case.

RM
Anonymous
a b à CPUs
May 12, 2005 7:03:28 PM

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

On 12 May 2005 09:56:25 -0700, "YKhan" <yjkhan@gmail.com> wrote:

>Robert Myers wrote:
>> 2. AMD processors don't have hyperthreading. Hyperthreading is
>> already in the benchmarks? Well, yes, but one of these days, they're
>> going to figure out how really to take advantage of HT. Honest.
>> Meanwhilst, the manager stuck with Intel processors that are
>> outperformed in benchmarks can say, "Yeah, but because of
>> hyperthreading, this is really like an 8-way box."
>
>Well, I just posted a story talking about how the Netburst architecture
>is likely going to disappear by 2006. Without Netburst's long
>pipelines, Hyperthreading becomes difficult with the short-pipeline
>architecture that's going to replace it. But Intel is going to try it
>anyways.
>
I'm feeling a little slow today. There isn't nearly the payoff for
hyperthreading when things like branch mispredicts are less expensive
(in clock ticks) because of a shorter pipeline, but that doesn't mean
hyperthreading is harder to implement.

Looking at Intel's marketing materials and comparing the disappointing
payoff (hyperthreading doesn't seem to improve units of useful work
per watt or per transistor), I conclude that hyperthreading is a
marketing gimmick and that Intel knows that, so it doesn't much matter
what the real payoff is, as long as it isn't too negative.

RM
May 13, 2005 1:17:52 AM

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?

Designed? Why? All the apps here are 64 bit.

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

Why is that a problem? x86 is rather well known. Doubling the register
width (and more importantly depth) isn't rocket-surgery.

Are you piling a little more FUD here?

--
Keith
May 13, 2005 1:38:18 AM

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

On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:

> On Thu, 12 May 2005 11:07:14 -0500, "Del Cecchi"
> <dcecchi.nospam@att.net> wrote:
>
>>
>>"David Kanter" <dkanter@gmail.com> wrote in message
>>news:1115912052.590234.270860@g14g2000cwa.googlegroups.com...
>>>> 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?
>>>
>>> How is that weak? It's a well known fact that not having a good tool
>>> chain can be a serious issue. I mean, let's be honest, when MIPS,
>>> POWERPC, SPARC etc. debuted, it was pretty darn obvious that their
>>> compilers were far less mature than those for S/360; don't you think
>>> that made adoption of those architectures a little hard to swallow for
>>> those used to S/360's development tools?
>>>
>>>> It still isn't clear that the Itanium architecture was a good idea,
>>> or
>>>> whether it was Intel's PS/2.
>>>
>>> Agreed...it will take time to tell.
>>>
>>>
>>It's weak because they have had what, 4 or 5 years to get some compilers out
>>there that work. If they haven't yet succeeded in doing so either it is
>>much harder than other architectures, lending credence to the idea that
>>Itanium was a bad idea or Intel is not trying very hard to make it happen,
>>lending credence to the idea that they are inept.
>>
> Almost anybody would have to vote for inept at this point wouldn't
> they? Were I professer at the Harvard Business School, I'd probably
> be looking around for some smart young whip to write a thesis on how
> this always happens to technology companies, with Intel (and
> Microsoft, btw) as only the latest case studies.

I'd read it, but I doubt you'd find enough people that would be willing to
talk to get enough information to fill a comic book. I do believe Intel
will try to bury the details (when was the first time you hread about
FS?)

> A software type (take it easy, Keith, he worked for a do-it-all chip
> company that I'll bet you've worked with, but no names) opined to me
> recently that AMD's advantage is that they really have no choice but to
> get outside help, so they get it. My interpolation is that, given the
> state of the industry, the best is generally available for hire by AMD
> unless they happen to work for Intel.

With? Me? I've never worked *with* any "do-it-all chip company". But I
do have to agree WRT AMD. Pretty smart cookies, eh?

> I'd love to be able to go back and look at the historical documents at
> Intel. What did they know and when did they know it? Even knowing what
> they _thought_ they knew would make a fascinating read.

Do you really thing these things exist? Come on, no one allows records to
live past their useful life. Sockholders could find 'em in a discovery
action. I'd like to know what and when HP figured it out. ;-)

> It isn't so much that they didn't get it right in four or five
> years...the problem is that hard. It's hard to comprehend what they
> were doing in terms of risk management, though. Not much, apparently.

Of course it's hard. The folks on CA and AFC were laughing at the
notion that it was even possible, given the state of the art.
These things had been tried before, and many in thouse gorups
were there when it was tried. Evidently Intel bet against the known art,
and lost.


>>I know that there is not much demand for Itanium stuff, but some cash
>>from HP and Intel and some contibutions to GCC or whatever would go a
>>long way in enhancing the offerings.
>>
> There was recently a Gelato meeting dealing with getting some serious
> help for gcc with Itanium. I haven't followed the details since the
> meeting to see whether anything really happened.
>
> I'll venture that no compiler solution to Itanium's problems is
> forthcoming. Not that significant progress isn't possible. It just
> won't be enough.



Gee, I heard that on CA at *least* five years ago. Some things never
change.

> That means death for Itanium? I'm less sure of that. It depends on how
> adventurous Intel is willing to be. The fact that execution pipes stall
> frequently really shouldn't be a serious problem for server
> applications. The idea that you have to keep a single pipe stuffed full
> and running all the time is mainframe and HPC thinking.

What is the incentive for anyone to move their application to Itanic?
It's a business issue. What is the payoff?

> The only thing Intel really has to preserve is the ISA. If you can add
> more execution paths without blowing the power consumption through the
> roof, you should be able to make practically any architecture get any
> kind of throughput you want as a multi-threaded server.

The only thing Intel *has* is the ISA. Why is that an issue for Intel's
customers? What does that benefit *them*?

> ...That's the path (lots of threads, who cares if they stall) I thought
> Intel was going to take with the core that I gather was being designed
> at Marlborough. That core, apparently, is dead, so who knows what Intel
> is going to do.

I've been wondering about that for three years.

> Should be posting to comp.arch so I could get major flames.

Whatever, but they're more into software ickyness. ;-)

--
Keith
Anonymous
a b à CPUs
May 13, 2005 2:08:22 AM

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

On Thu, 12 May 2005 08:27:32 -0400, Robert Myers
<rmyers1400@comcast.net> wrote:

>On Wed, 11 May 2005 21:08:34 -0400, Tony Hill
><hilla_nospam_20@yahoo.ca> wrote:
>
>>
>>Wow.. that's an extraordinarily WEAK response by Intel.
>>
>>"AMD's integrated memory controller is bad because a year from now
>>OEMs will have to requalify their systems for DDR2 memory"?
>>
>>Intel better hope that they've got a better answer than that!
>>
>
>I'd say it's a fairly shrewd response, and it's more than what you
>quoted:
>
>1. AMD has made a short-sighted decision by sticking with DDR when
>DDR2 is the longer term solution. Your response: buyers don't or
>shouldn't care, because all the hassle will be someone else's problem.

Not at all, more that you WILL have to change the platform in a year
anyway, regardless of whether it's Intel or AMD, DDR, DDR2 or
whatever. Platforms do change, and they change regularly.

I like how Intel conveniently left out that their customers will need
to change their platform for dual-core chips while AMD customers will
not.

>My only quibble with Intel's response would be that they didn't
>_quite_ close the loop by saying: you remember how hard it's been
>sometimes to get platforms for AMD processors you could really count
>on? Each time you change memory technology, you have to start over.
>FUD? Of course. This is marketing.

I still say that it's extremely weak FUD given that DDR2 currently
does nothing other than add ~$100 to the price tag of the system.
Even DDR2-667 hasn't really shown to improve performance over DDR400
by any noticeable margin. Hmm, what a surprise, increasing bandwidth
doesn't help any when you also increase latency.

As for AMD platforms, well now that's another question, but this FUD
is nothing new. AMD (and OEMs using AMD processors) have been dealing
with this "problem" (sometimes real, though usually just perceived)
ever since the first Athlon came out back in '90.

>2. AMD processors don't have hyperthreading. Hyperthreading is
>already in the benchmarks? Well, yes, but one of these days, they're
>going to figure out how really to take advantage of HT. Honest.
>Meanwhilst, the manager stuck with Intel processors that are
>outperformed in benchmarks can say, "Yeah, but because of
>hyperthreading, this is really like an 8-way box."

I didn't even comment on this because it was just stupid beyond
belief. First off, Intel chips don't have hyperthreading either, or
at least not their dual-core chips other than the Extremely Expensive
Edition.

Ohh, and the whole thing about how Hyperthreading will show MORE of an
advantage when you get multiple cores vs. single core chips. Whoever
said that was just smoking the crack-pipe I think.

>3. AMD doesn't have the capacity to be Intel. That's the one that
>really counts for managers with their thinking caps on.

Now this is the kicker, though again it's the same argument that AMD
has been dealing with since ~'97 when Fab25 came on-line for their K6
chips. Surprisingly, for the past 5 years it has been INTEL, and not
AMD, that has had product shortage problems. After yelling and
screaming for 7 or 8 years about AMD not being able to deliver only to
see AMD do a better job of delivering products than Intel, everyone
except Dell has stopped listening.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
May 13, 2005 7:27:51 AM

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

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:a6v7819l9114vm74nr3g8qt990fmbu722c@4ax.com...
>
> I still say that it's extremely weak FUD given that DDR2 currently
> does nothing other than add ~$100 to the price tag of the system.
> Even DDR2-667 hasn't really shown to improve performance over DDR400
> by any noticeable margin. Hmm, what a surprise, increasing
bandwidth
> doesn't help any when you also increase latency.

Didn't another company discover that a while back? Brambuss,
something like that? ;-)
Anonymous
a b à CPUs
May 13, 2005 12:56:06 PM

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

On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:

>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>

>
>> I'd love to be able to go back and look at the historical documents at
>> Intel. What did they know and when did they know it? Even knowing what
>> they _thought_ they knew would make a fascinating read.
>
>Do you really thing these things exist?

Tech types are packrats. No staff type ever wrote a briefing saying
"This is what we expected, this is what we got, and here's why we
didn't get what we expected?"

>Come on, no one allows records to
>live past their useful life. Sockholders could find 'em in a discovery
>action. I'd like to know what and when HP figured it out. ;-)
>
>> It isn't so much that they didn't get it right in four or five
>> years...the problem is that hard. It's hard to comprehend what they
>> were doing in terms of risk management, though. Not much, apparently.
>
>Of course it's hard. The folks on CA and AFC were laughing at the
>notion that it was even possible, given the state of the art.
>These things had been tried before, and many in thouse gorups
>were there when it was tried. Evidently Intel bet against the known art,
>and lost.
>
You've never been around when something that "everybody knew" turned
out to be wrong? "Everybody knew" you couldn't make features smaller
than the wavelength, for example.

IBM went through a similar phase: The only reason it hasn't been done
is because nobody else has done it right. We've got the money to do
it right.

The key problem that underlies at least some of Itanium's difficulties
is a core problem for IT and it isn't going to go away: how to
anticipate movement of data to minimize time on the critical path.
The same problem shows up with memory access, with disk access, and
now with serving web pages. The technology continues to move since
Itanium was dreamed up. And who knows if they even understood how
much of a problem getting the data in would be would be--I don't think
they did. I'd be grateful, in fact, for a citation that said that
they did. Itanium was already on the launching pad before people
started saying "Oh, my g*d" about the memory wall. Since Intel
effectively made the same decision *again* with NetBurst, though, one
is inclined to think that Intel continued to think it had a way to
beat the problem. Wonder who was lying to whom?


>>
>> I'll venture that no compiler solution to Itanium's problems is
>> forthcoming. Not that significant progress isn't possible. It just
>> won't be enough.
>
>Gee, I heard that on CA at *least* five years ago. Some things never
>change.
>
It's a moving target.

>> That means death for Itanium? I'm less sure of that. It depends on how
>> adventurous Intel is willing to be. The fact that execution pipes stall
>> frequently really shouldn't be a serious problem for server
>> applications. The idea that you have to keep a single pipe stuffed full
>> and running all the time is mainframe and HPC thinking.
>
>What is the incentive for anyone to move their application to Itanic?
>It's a business issue. What is the payoff?
>
>> The only thing Intel really has to preserve is the ISA. If you can add
>> more execution paths without blowing the power consumption through the
>> roof, you should be able to make practically any architecture get any
>> kind of throughput you want as a multi-threaded server.
>
>The only thing Intel *has* is the ISA. Why is that an issue for Intel's
>customers? What does that benefit *them*?
>

The advantage is that it's not x86 and it's not made by IBM. Your bet
is that the industry will converge on x86. It may well, except for a
particularly lucrative part of the market. That's the part that IBM
has and that Intel wants. A different ISA won't help them to get it?
Apparently Intel thinks otherwise.

Why would *customers* care? Because they don't want their enterprise
workhorses running on a legacy PC processor that migrated upward. It
seems increasingly unlikely, but if Itanium ever does make it to the
desktop, it will be clear that it is migrating downward. You can
think that's irrelevant, if you like, but I don't. If you're going to
wheel out IBM big iron, you don't want to be wheeling in a PC to
replace it.

It's true. When I talk to people who _ought_ to be interested,
they're not. They've already tried it, found out that it's hard and
there's no real payoff, and moved on.

RM
Anonymous
a b à CPUs
May 13, 2005 1:23:02 PM

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

"Robert Myers" <rmyers1400@comcast.net> wrote in message
news:r55981paekdd0ctafvghmddcm7lqvpr4to@4ax.com...
> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>
>
>>
>>> I'd love to be able to go back and look at the historical documents at
>>> Intel. What did they know and when did they know it? Even knowing what
>>> they _thought_ they knew would make a fascinating read.
>>
>>Do you really thing these things exist?
>
> Tech types are packrats. No staff type ever wrote a briefing saying
> "This is what we expected, this is what we got, and here's why we
> didn't get what we expected?"
>
>>Come on, no one allows records to
>>live past their useful life. Sockholders could find 'em in a discovery
>>action. I'd like to know what and when HP figured it out. ;-)

You don't know much about engineers do you? If the document or presentation
existed, there is a copy on somebody's C: or ~/ somewhere.
>>
>>> It isn't so much that they didn't get it right in four or five
>>> years...the problem is that hard. It's hard to comprehend what they
>>> were doing in terms of risk management, though. Not much, apparently.
>>
>>Of course it's hard. The folks on CA and AFC were laughing at the
>>notion that it was even possible, given the state of the art.
>>These things had been tried before, and many in thouse gorups
>>were there when it was tried. Evidently Intel bet against the known art,
>>and lost.
>>
> You've never been around when something that "everybody knew" turned
> out to be wrong? "Everybody knew" you couldn't make features smaller
> than the wavelength, for example.
>
> IBM went through a similar phase: The only reason it hasn't been done
> is because nobody else has done it right. We've got the money to do
> it right.

And in the case of VLIW, I think IBM caught on pretty early in that process.
But maybe they were more humble than Intel by then. By the time Itanium hit
public notice, I wasn't hearing much about VLIW.
>
> The key problem that underlies at least some of Itanium's difficulties
> is a core problem for IT and it isn't going to go away: how to
> anticipate movement of data to minimize time on the critical path.
> The same problem shows up with memory access, with disk access, and
> now with serving web pages. The technology continues to move since
> Itanium was dreamed up. And who knows if they even understood how
> much of a problem getting the data in would be would be--I don't think
> they did. I'd be grateful, in fact, for a citation that said that
> they did. Itanium was already on the launching pad before people
> started saying "Oh, my g*d" about the memory wall. Since Intel
> effectively made the same decision *again* with NetBurst, though, one
> is inclined to think that Intel continued to think it had a way to
> beat the problem. Wonder who was lying to whom?

Oh please. People have been talking about the memory wall and evaluating
its effects for a long time. Do you think computer architects just fell off
the turnip truck? Hell, we even heard about it up here on the frozen
tundra. The real error is the common one of believing someone who says
"This time it is different". Often, when someone says that it turns out not
to be true, whether talking about the stock market or computer architecture.


>
>>>
>>> I'll venture that no compiler solution to Itanium's problems is
>>> forthcoming. Not that significant progress isn't possible. It just
>>> won't be enough.
>>
>>Gee, I heard that on CA at *least* five years ago. Some things never
>>change.
>>
> It's a moving target.

Some times projects with "invention required" don't work out.
>
>>> That means death for Itanium? I'm less sure of that. It depends on how
>>> adventurous Intel is willing to be. The fact that execution pipes stall
>>> frequently really shouldn't be a serious problem for server
>>> applications. The idea that you have to keep a single pipe stuffed full
>>> and running all the time is mainframe and HPC thinking.
>>
>>What is the incentive for anyone to move their application to Itanic?
>>It's a business issue. What is the payoff?
>>
>>> The only thing Intel really has to preserve is the ISA. If you can add
>>> more execution paths without blowing the power consumption through the
>>> roof, you should be able to make practically any architecture get any
>>> kind of throughput you want as a multi-threaded server.
>>
>>The only thing Intel *has* is the ISA. Why is that an issue for Intel's
>>customers? What does that benefit *them*?
>>
>
> The advantage is that it's not x86 and it's not made by IBM. Your bet
> is that the industry will converge on x86. It may well, except for a
> particularly lucrative part of the market. That's the part that IBM
> has and that Intel wants. A different ISA won't help them to get it?
> Apparently Intel thinks otherwise.
>
> Why would *customers* care? Because they don't want their enterprise
> workhorses running on a legacy PC processor that migrated upward. It
> seems increasingly unlikely, but if Itanium ever does make it to the
> desktop, it will be clear that it is migrating downward. You can
> think that's irrelevant, if you like, but I don't. If you're going to
> wheel out IBM big iron, you don't want to be wheeling in a PC to
> replace it.
>
> It's true. When I talk to people who _ought_ to be interested,
> they're not. They've already tried it, found out that it's hard and
> there's no real payoff, and moved on.
>
> RM

It would be interesting to know what Intel's future Itanium plans are. HP
has a problem, having apparently tied their servers pretty solidly to
Itanium, if Intel de-prioritizes it. And didn't HP sell most of their
microprocessor folks to Intel?

del
Anonymous
a b à CPUs
May 13, 2005 1:50:30 PM

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

Del Cecchi wrote:

>It would be interesting to know what Intel's future Itanium plans are. HP
>has a problem, having apparently tied their servers pretty solidly to
>Itanium, if Intel de-prioritizes it. And didn't HP sell most of their
>microprocessor folks to Intel?

Small wonder that companies like Intel and Microsoft continue to
dominate industries, when their competitors are so incredibly feeble
that they fold their hands at the mere announcement of a new
"world-beating" product.
Anonymous
a b à CPUs
May 13, 2005 2:59:45 PM

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

On Fri, 13 May 2005 09:23:02 -0500, "Del Cecchi"
<dcecchi.nospam@att.net> wrote:

>
>"Robert Myers" <rmyers1400@comcast.net> wrote in message
>news:r55981paekdd0ctafvghmddcm7lqvpr4to@4ax.com...
>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>
>>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>>
>>
>>>
>>>> I'd love to be able to go back and look at the historical documents at
>>>> Intel. What did they know and when did they know it? Even knowing what
>>>> they _thought_ they knew would make a fascinating read.
>>>
>>>Do you really thing these things exist?
>>
>> Tech types are packrats. No staff type ever wrote a briefing saying
>> "This is what we expected, this is what we got, and here's why we
>> didn't get what we expected?"
>>
>>>Come on, no one allows records to
>>>live past their useful life. Sockholders could find 'em in a discovery
>>>action. I'd like to know what and when HP figured it out. ;-)
>
>You don't know much about engineers do you? If the document or presentation
>existed, there is a copy on somebody's C: or ~/ somewhere.

I don't know. Does Keith, who wrote that, know much about engineers?
I agree with you. Somebody's got the goods.

>>>
>>>> It isn't so much that they didn't get it right in four or five
>>>> years...the problem is that hard. It's hard to comprehend what they
>>>> were doing in terms of risk management, though. Not much, apparently.
>>>
>>>Of course it's hard. The folks on CA and AFC were laughing at the
>>>notion that it was even possible, given the state of the art.
>>>These things had been tried before, and many in thouse gorups
>>>were there when it was tried. Evidently Intel bet against the known art,
>>>and lost.
>>>
>> You've never been around when something that "everybody knew" turned
>> out to be wrong? "Everybody knew" you couldn't make features smaller
>> than the wavelength, for example.
>>
>> IBM went through a similar phase: The only reason it hasn't been done
>> is because nobody else has done it right. We've got the money to do
>> it right.
>
>And in the case of VLIW, I think IBM caught on pretty early in that process.
>But maybe they were more humble than Intel by then. By the time Itanium hit
>public notice, I wasn't hearing much about VLIW.

Translation: IBM was in a fight for its life. Something about the
sight of the gallows and concentrating the mind.

>>
>> The key problem that underlies at least some of Itanium's difficulties
>> is a core problem for IT and it isn't going to go away: how to
>> anticipate movement of data to minimize time on the critical path.
>> The same problem shows up with memory access, with disk access, and
>> now with serving web pages. The technology continues to move since
>> Itanium was dreamed up. And who knows if they even understood how
>> much of a problem getting the data in would be would be--I don't think
>> they did. I'd be grateful, in fact, for a citation that said that
>> they did. Itanium was already on the launching pad before people
>> started saying "Oh, my g*d" about the memory wall. Since Intel
>> effectively made the same decision *again* with NetBurst, though, one
>> is inclined to think that Intel continued to think it had a way to
>> beat the problem. Wonder who was lying to whom?
>
>Oh please. People have been talking about the memory wall and evaluating
>its effects for a long time. Do you think computer architects just fell off
>the turnip truck? Hell, we even heard about it up here on the frozen
>tundra. The real error is the common one of believing someone who says
>"This time it is different". Often, when someone says that it turns out not
>to be true, whether talking about the stock market or computer architecture.
>

I date the term "memory wall" from a 1995 article in Compter
Architecture News by Wulf and McKee.

http://citeseer.ist.psu.edu/cache/papers/cs/2494/ftp:zS...

Engineers and computer architects probably talked about the problem
long before the article appeared, but the Wulf and McKee article
itself is a bit naive, as if cache were all about reuse and that there
would be nothing to be done about "first use" cache misses. Had that
turned out to be true, of course, faster processors would long ago
have become completely pointless, and everything would be massively
parallel processing by now.

I don't think anyone could forsee at that time what a big deal
out-of-order processing would turn out to be. In some ways, Intel/HP
just jumped the gun. Had they (for example) waited until the Pentium
II had been introduced, the future would have been much easier to
forsee, and it would be harder to forgive them for adopting an ISA
that would make competing even with x86 much more difficult.
>
>>
>>>>
>>>> I'll venture that no compiler solution to Itanium's problems is
>>>> forthcoming. Not that significant progress isn't possible. It just
>>>> won't be enough.
>>>
>>>Gee, I heard that on CA at *least* five years ago. Some things never
>>>change.
>>>
>> It's a moving target.
>
>Some times projects with "invention required" don't work out.

The compilers are getting better, just not fast enough compared to the
competition.

<snip>

>
>It would be interesting to know what Intel's future Itanium plans are. HP
>has a problem, having apparently tied their servers pretty solidly to
>Itanium, if Intel de-prioritizes it. And didn't HP sell most of their
>microprocessor folks to Intel?
>
That begs the question of what HP's bigger picture view of the future
is. There must be more on the table than just what processor their
big boxes will use.

As to what Intel thinks, it's hard to imagine Intel disburdening
itself of Itanium while HP is still relying on it. Cutting HP (or
equivalent) loose would close off many futures to Intel.

RM
Anonymous
a b à CPUs
May 13, 2005 5:04:52 PM

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

Robert Myers wrote:
> I'm feeling a little slow today. There isn't nearly the payoff for
> hyperthreading when things like branch mispredicts are less expensive
> (in clock ticks) because of a shorter pipeline, but that doesn't mean
> hyperthreading is harder to implement.
>
> Looking at Intel's marketing materials and comparing the
disappointing
> payoff (hyperthreading doesn't seem to improve units of useful work
> per watt or per transistor), I conclude that hyperthreading is a
> marketing gimmick and that Intel knows that, so it doesn't much
matter
> what the real payoff is, as long as it isn't too negative.

I personally assume that they're going to be happy that they have
multicores and forget Hyperthreading.

Plus today it looks like a legitimate security hole in Hyperthreading
has been found, and possibly Intel might not be too happy pushing
Hyperthreading as a marketing gimick for much longer.

http://www.daemonology.net/papers/htt.pdf

Yousuf Khan
Anonymous
a b à CPUs
May 13, 2005 5:14:23 PM

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

Robert Myers wrote:
> >The only thing Intel *has* is the ISA. Why is that an issue for
Intel's
> >customers? What does that benefit *them*?
> >
>
> The advantage is that it's not x86 and it's not made by IBM. Your
bet
> is that the industry will converge on x86. It may well, except for a
> particularly lucrative part of the market. That's the part that IBM
> has and that Intel wants. A different ISA won't help them to get it?
> Apparently Intel thinks otherwise.
>
> Why would *customers* care? Because they don't want their enterprise
> workhorses running on a legacy PC processor that migrated upward. It
> seems increasingly unlikely, but if Itanium ever does make it to the
> desktop, it will be clear that it is migrating downward. You can
> think that's irrelevant, if you like, but I don't. If you're going
to
> wheel out IBM big iron, you don't want to be wheeling in a PC to
> replace it.
>
> It's true. When I talk to people who _ought_ to be interested,
> they're not. They've already tried it, found out that it's hard and
> there's no real payoff, and moved on.

These days, the enterprise is evolving towards upgraded PCs. It's a sad
sight, yes, but it's happening nonetheless. But it's not so bad, the
PCs are adopting features from mainframe and Unix servers as they move
up.

Yousuf Khan
Anonymous
a b à CPUs
May 13, 2005 6:34:23 PM

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

"Robert Myers" <rmyers1400@comcast.net> wrote in message
news:l8f981p59tu6dhh5q2f8jg13s6jv0643gk@4ax.com...

>
> I date the term "memory wall" from a 1995 article in Compter
> Architecture News by Wulf and McKee.
>
> http://citeseer.ist.psu.edu/cache/papers/cs/2494/ftp:zS...
>
> Engineers and computer architects probably talked about the problem
> long before the article appeared, but the Wulf and McKee article
> itself is a bit naive, as if cache were all about reuse and that there
> would be nothing to be done about "first use" cache misses. Had that
> turned out to be true, of course, faster processors would long ago
> have become completely pointless, and everything would be massively
> parallel processing by now.
>
That's the trouble with the future, it's so hard to predict. (someone
famous said that). Rather than "memory wall" if you search for "von neuman
bottleneck" it might go back a ways further. Certainly the guys that
invented caches had a clue. In IBM's case that was long about 360/85 time
or the late 60's. And the folks studying and simulating performance
certainly understood the issues. Of course folks got way more out of the
old way that anyone anticipated, but all things must come to an end.

del
May 14, 2005 3:34:15 PM

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

On Fri, 13 May 2005 03:27:51 +0000, Felger Carbon wrote:

> "Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
> news:a6v7819l9114vm74nr3g8qt990fmbu722c@4ax.com...
>>
>> I still say that it's extremely weak FUD given that DDR2 currently
>> does nothing other than add ~$100 to the price tag of the system.
>> Even DDR2-667 hasn't really shown to improve performance over DDR400
>> by any noticeable margin. Hmm, what a surprise, increasing
> bandwidth
>> doesn't help any when you also increase latency.

Bandwidth only matters if you don't have enough and more helps not a bit.
Latency is forever.

> Didn't another company discover that a while back? Brambuss, something
> like that? ;-)

DamBu$$?

--
Keith
May 14, 2005 3:38:45 PM

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

On Fri, 13 May 2005 09:23:02 -0500, Del Cecchi wrote:

>
> "Robert Myers" <rmyers1400@comcast.net> wrote in message
> news:r55981paekdd0ctafvghmddcm7lqvpr4to@4ax.com...
>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>
>>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>>
>>
>>>
>>>> I'd love to be able to go back and look at the historical documents at
>>>> Intel. What did they know and when did they know it? Even knowing what
>>>> they _thought_ they knew would make a fascinating read.
>>>
>>>Do you really thing these things exist?
>>
>> Tech types are packrats. No staff type ever wrote a briefing saying
>> "This is what we expected, this is what we got, and here's why we
>> didn't get what we expected?"
>>
>>>Come on, no one allows records to
>>>live past their useful life. Sockholders could find 'em in a discovery
>>>action. I'd like to know what and when HP figured it out. ;-)
>
> You don't know much about engineers do you? If the document or presentation
> existed, there is a copy on somebody's C: or ~/ somewhere.

Well, since I said the above; yes I do know a little about engineers. ;-)
Do you save all your email in seperate folders so the disk munchers can't
find it when it expires? I don't bother. The PHBs don't want any
evidence. ;-)

--
Keith
May 14, 2005 4:00:35 PM

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

On Fri, 13 May 2005 08:56:06 -0400, Robert Myers wrote:

> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>
>
>>
>>> I'd love to be able to go back and look at the historical documents at
>>> Intel. What did they know and when did they know it? Even knowing what
>>> they _thought_ they knew would make a fascinating read.
>>
>>Do you really thing these things exist?
>
> Tech types are packrats. No staff type ever wrote a briefing saying
> "This is what we expected, this is what we got, and here's why we
> didn't get what we expected?"

Tech types are often overruled by PHB types. I'd expect these sorts of
discussions between high-level architects and the evidence would be
"supressed".

>>Come on, no one allows records to
>>live past their useful life. Sockholders could find 'em in a discovery
>>action. I'd like to know what and when HP figured it out. ;-)
>>
>>> It isn't so much that they didn't get it right in four or five
>>> years...the problem is that hard. It's hard to comprehend what they
>>> were doing in terms of risk management, though. Not much, apparently.
>>
>>Of course it's hard. The folks on CA and AFC were laughing at the
>>notion that it was even possible, given the state of the art.
>>These things had been tried before, and many in thouse gorups
>>were there when it was tried. Evidently Intel bet against the known art,
>>and lost.
>>
> You've never been around when something that "everybody knew" turned
> out to be wrong? "Everybody knew" you couldn't make features smaller
> than the wavelength, for example.

I rather "know" that C is about as fast as it gets. I'm not investing in
a company that thinks it knows better.

> IBM went through a similar phase: The only reason it hasn't been done is
> because nobody else has done it right. We've got the money to do it
> right.

After a few billion$ were spent by others, why don't we flush a few more
of our stock holder's. Money's cheap.

> The key problem that underlies at least some of Itanium's difficulties
> is a core problem for IT and it isn't going to go away: how to
> anticipate movement of data to minimize time on the critical path. The
> same problem shows up with memory access, with disk access, and now with
> serving web pages. The technology continues to move since Itanium was
> dreamed up. And who knows if they even understood how much of a problem
> getting the data in would be would be--I don't think they did.

I guess Intel architects don't read CA? These issues were discussed there
whan Itanic was first announced.

> I'd be
> grateful, in fact, for a citation that said that they did. Itanium was
> already on the launching pad before people started saying "Oh, my g*d"
> about the memory wall. Since Intel effectively made the same decision
> *again* with NetBurst, though, one is inclined to think that Intel
> continued to think it had a way to beat the problem. Wonder who was
> lying to whom?

Itanic may have been on the launching pad before people discussed this,
but these people discussed these problems as soon as they saw the monster.
Apparently you don't think Intel's architects are as sharp as those who
publicly post to CA.
>
>>> I'll venture that no compiler solution to Itanium's problems is
>>> forthcoming. Not that significant progress isn't possible. It just
>>> won't be enough.
>>
>>Gee, I heard that on CA at *least* five years ago. Some things never
>>change.
>>
> It's a moving target.

It's dead Jim.

>>> That means death for Itanium? I'm less sure of that. It depends on
>>> how adventurous Intel is willing to be. The fact that execution pipes
>>> stall frequently really shouldn't be a serious problem for server
>>> applications. The idea that you have to keep a single pipe stuffed
>>> full and running all the time is mainframe and HPC thinking.
>>
>>What is the incentive for anyone to move their application to Itanic?
>>It's a business issue. What is the payoff?
>>
>>> The only thing Intel really has to preserve is the ISA. If you can
>>> add more execution paths without blowing the power consumption through
>>> the roof, you should be able to make practically any architecture get
>>> any kind of throughput you want as a multi-threaded server.
>>
>>The only thing Intel *has* is the ISA. Why is that an issue for Intel's
>>customers? What does that benefit *them*?
>>
>>
> The advantage is that it's not x86 and it's not made by IBM. Your bet
> is that the industry will converge on x86. It may well, except for a
> particularly lucrative part of the market. That's the part that IBM has
> and that Intel wants. A different ISA won't help them to get it?
> Apparently Intel thinks otherwise.

Why does "made by IBM" make it bad? A proprietary architecture is a
proprietary architecture (Itanic much more so than PowerPC, in fact).
Why would one take applications from a more or less open architecture
(x86) to a closed one? Why would you trust your enterprise to Intel as
opposed to IBM? ...particularly when one has a tad more experience in the
market.

No, my bet is *not* that the industry will converge on x86. My bet is
that no x86 applications will move to other platforms in the forseeable
future. My bet is that x86 will live on far longer than Itanic. My bet
was that Itanic wasn't going to displace x86. My bet was that Intel
stubbed their toe with Itanic, and AMD gave them a gut-kick while they
weren't paying attention. So far I've been right.

If my bet were that x86 was everything there is, I'd be rather stupid
doing what I do. Well...

> Why would *customers* care? Because they don't want their enterprise
> workhorses running on a legacy PC processor that migrated upward. It
> seems increasingly unlikely, but if Itanium ever does make it to the
> desktop, it will be clear that it is migrating downward. You can think
> that's irrelevant, if you like, but I don't. If you're going to wheel
> out IBM big iron, you don't want to be wheeling in a PC to replace it.

That was certainly Intel's plan. Too bad it was fatally flawed by a
turkey of an architecture. Intel needed a bust-out architecture to pull
anything like the off, but chose one that needed more than a little
invention than they could handle. Meanwhile everyone else scaled up their
performance. ...sorta what Intel (with x86) did to RISC.

> It's true. When I talk to people who _ought_ to be interested, they're
> not. They've already tried it, found out that it's hard and there's no
> real payoff, and moved on.

Meanwhile, AMD swiped Intel's lunch money. Intel doesn't show pretty
poor signs of catching up.

--
Keith
Anonymous
a b à CPUs
May 14, 2005 4:10:13 PM

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

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.05.14.15.38.42.559702@att.bizzzz...
> On Fri, 13 May 2005 09:23:02 -0500, Del Cecchi wrote:
>
>>
>> "Robert Myers" <rmyers1400@comcast.net> wrote in message
>> news:r55981paekdd0ctafvghmddcm7lqvpr4to@4ax.com...
>>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>>
>>>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>>>
>>>
>>>>
>>>>> I'd love to be able to go back and look at the historical documents at
>>>>> Intel. What did they know and when did they know it? Even knowing
>>>>> what
>>>>> they _thought_ they knew would make a fascinating read.
>>>>
>>>>Do you really thing these things exist?
>>>
>>> Tech types are packrats. No staff type ever wrote a briefing saying
>>> "This is what we expected, this is what we got, and here's why we
>>> didn't get what we expected?"
>>>
>>>>Come on, no one allows records to
>>>>live past their useful life. Sockholders could find 'em in a discovery
>>>>action. I'd like to know what and when HP figured it out. ;-)
>>
>> You don't know much about engineers do you? If the document or
>> presentation
>> existed, there is a copy on somebody's C: or ~/ somewhere.
>
> Well, since I said the above; yes I do know a little about engineers. ;-)
> Do you save all your email in seperate folders so the disk munchers can't
> find it when it expires? I don't bother. The PHBs don't want any
> evidence. ;-)
>
> --
> Keith

Nope, but I detach interesting .ppt and .pdf files and stash them on c: or
v: or h:
don't you?
May 14, 2005 5:19:03 PM

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

On Sat, 14 May 2005 12:10:13 -0500, Del Cecchi wrote:

>
> "keith" <krw@att.bizzzz> wrote in message
> news:p an.2005.05.14.15.38.42.559702@att.bizzzz...
>> On Fri, 13 May 2005 09:23:02 -0500, Del Cecchi wrote:
>>
>>>
>>> "Robert Myers" <rmyers1400@comcast.net> wrote in message
>>> news:r55981paekdd0ctafvghmddcm7lqvpr4to@4ax.com...
>>>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>>>
>>>>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>>>>
>>>>
>>>>>
>>>>>> I'd love to be able to go back and look at the historical documents at
>>>>>> Intel. What did they know and when did they know it? Even knowing
>>>>>> what
>>>>>> they _thought_ they knew would make a fascinating read.
>>>>>
>>>>>Do you really thing these things exist?
>>>>
>>>> Tech types are packrats. No staff type ever wrote a briefing saying
>>>> "This is what we expected, this is what we got, and here's why we
>>>> didn't get what we expected?"
>>>>
>>>>>Come on, no one allows records to
>>>>>live past their useful life. Sockholders could find 'em in a discovery
>>>>>action. I'd like to know what and when HP figured it out. ;-)
>>>
>>> You don't know much about engineers do you? If the document or
>>> presentation
>>> existed, there is a copy on somebody's C: or ~/ somewhere.
>>
>> Well, since I said the above; yes I do know a little about engineers. ;-)
>> Do you save all your email in seperate folders so the disk munchers can't
>> find it when it expires? I don't bother. The PHBs don't want any
>> evidence. ;-)
>>
>> --
>> Keith
>
> Nope, but I detach interesting .ppt and .pdf files and stash them on c: or
> v: or h:
> don't you?

Rarely. I rarely get interesting files in emails (they're on web sites
also under PHB control). I was thinking more along the lines of strategy
and direction discussions, rather than the mundane bit-banging details.

--
Keith
Anonymous
a b à CPUs
May 14, 2005 5:19:04 PM

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

"keith" <krw@att.bizzzz> wrote in message
news:p an.2005.05.14.17.19.02.402390@att.bizzzz...
> On Sat, 14 May 2005 12:10:13 -0500, Del Cecchi wrote:
>
>>
>> "keith" <krw@att.bizzzz> wrote in message
>> news:p an.2005.05.14.15.38.42.559702@att.bizzzz...
>>> On Fri, 13 May 2005 09:23:02 -0500, Del Cecchi wrote:
>>>
>>>>
>>>> "Robert Myers" <rmyers1400@comcast.net> wrote in message
>>>> news:r55981paekdd0ctafvghmddcm7lqvpr4to@4ax.com...
>>>>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>>>>
>>>>>>On Thu, 12 May 2005 12:46:19 -0400, Robert Myers wrote:
>>>>>>
>>>>>
>>>>>>
>>>>>>> I'd love to be able to go back and look at the historical documents
>>>>>>> at
>>>>>>> Intel. What did they know and when did they know it? Even knowing
>>>>>>> what
>>>>>>> they _thought_ they knew would make a fascinating read.
>>>>>>
>>>>>>Do you really thing these things exist?
>>>>>
>>>>> Tech types are packrats. No staff type ever wrote a briefing saying
>>>>> "This is what we expected, this is what we got, and here's why we
>>>>> didn't get what we expected?"
>>>>>
>>>>>>Come on, no one allows records to
>>>>>>live past their useful life. Sockholders could find 'em in a
>>>>>>discovery
>>>>>>action. I'd like to know what and when HP figured it out. ;-)
>>>>
>>>> You don't know much about engineers do you? If the document or
>>>> presentation
>>>> existed, there is a copy on somebody's C: or ~/ somewhere.
>>>
>>> Well, since I said the above; yes I do know a little about engineers.
>>> ;-)
>>> Do you save all your email in seperate folders so the disk munchers
>>> can't
>>> find it when it expires? I don't bother. The PHBs don't want any
>>> evidence. ;-)
>>>
>>> --
>>> Keith
>>
>> Nope, but I detach interesting .ppt and .pdf files and stash them on c:
>> or
>> v: or h:
>> don't you?
>
> Rarely. I rarely get interesting files in emails (they're on web sites
> also under PHB control). I was thinking more along the lines of strategy
> and direction discussions, rather than the mundane bit-banging details.
>
> --
> Keith
>
Those are on notes databases. Detachable too.

:-)

del
Anonymous
a b à CPUs
May 14, 2005 8:40:10 PM

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

On Sat, 14 May 2005 12:00:35 -0400, keith <krw@att.bizzzz> wrote:

>On Fri, 13 May 2005 08:56:06 -0400, Robert Myers wrote:
>
>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>

>
>> IBM went through a similar phase: The only reason it hasn't been done is
>> because nobody else has done it right. We've got the money to do it
>> right.
>
>After a few billion$ were spent by others, why don't we flush a few more
>of our stock holder's. Money's cheap.
>
I have no idea what Intel might do as a Plan B. I don't think there
is a Plan B. I think Itanium is it. They would have been better off
with Alpha? I think that subject's been beaten to death. They needed
something.

>> The key problem that underlies at least some of Itanium's difficulties
>> is a core problem for IT and it isn't going to go away: how to
>> anticipate movement of data to minimize time on the critical path. The
>> same problem shows up with memory access, with disk access, and now with
>> serving web pages. The technology continues to move since Itanium was
>> dreamed up. And who knows if they even understood how much of a problem
>> getting the data in would be would be--I don't think they did.
>
>I guess Intel architects don't read CA? These issues were discussed there
>whan Itanic was first announced.
>
I don't know what to say if you really think usenet posts to comp.arch
are the last word on a subject.

>> I'd be
>> grateful, in fact, for a citation that said that they did. Itanium was
>> already on the launching pad before people started saying "Oh, my g*d"
>> about the memory wall. Since Intel effectively made the same decision
>> *again* with NetBurst, though, one is inclined to think that Intel
>> continued to think it had a way to beat the problem. Wonder who was
>> lying to whom?
>
>Itanic may have been on the launching pad before people discussed this,
>but these people discussed these problems as soon as they saw the monster.
>Apparently you don't think Intel's architects are as sharp as those who
>publicly post to CA.

I don't know what you mean. NetBurst was the same flavor of wishful
thinking as Itanium: we'll figure out a way to get the compiler to
schedule it, even if the processor has the agility of an oil tanker.

>>>
>> The advantage is that it's not x86 and it's not made by IBM. Your bet
>> is that the industry will converge on x86. It may well, except for a
>> particularly lucrative part of the market. That's the part that IBM has
>> and that Intel wants. A different ISA won't help them to get it?
>> Apparently Intel thinks otherwise.
>
>Why does "made by IBM" make it bad? A proprietary architecture is a
>proprietary architecture (Itanic much more so than PowerPC, in fact).
>Why would one take applications from a more or less open architecture
>(x86) to a closed one? Why would you trust your enterprise to Intel as
>opposed to IBM? ...particularly when one has a tad more experience in the
>market.
>
*Somebody* is going to be using *some* architecture not proprietary to
IBM to make high-end boxes. It doesn't matter whether I think it's
good or bad. It's going to happen. If Itanium dies, it will be
something else.

>That was certainly Intel's plan. Too bad it was fatally flawed by a
>turkey of an architecture. Intel needed a bust-out architecture to pull
>anything like the off, but chose one that needed more than a little
>invention than they could handle. Meanwhile everyone else scaled up their
>performance. ...sorta what Intel (with x86) did to RISC.
>
Intel was not alone. Elbrus was going to conquer the world with its
VLIW architecture. I think Intel bought whatever was left of Elbrus.

>> It's true. When I talk to people who _ought_ to be interested, they're
>> not. They've already tried it, found out that it's hard and there's no
>> real payoff, and moved on.
>
>Meanwhile, AMD swiped Intel's lunch money. Intel doesn't show pretty
>poor signs of catching up.

For all that, Intel's feathers don't seem to be too ruffled. If it's
all a bluff, they bluff very effectively.

RM
May 15, 2005 2:47:30 AM

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

On Sat, 14 May 2005 16:40:10 -0400, Robert Myers wrote:

> On Sat, 14 May 2005 12:00:35 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Fri, 13 May 2005 08:56:06 -0400, Robert Myers wrote:
>>
>>> On Thu, 12 May 2005 21:38:18 -0400, keith <krw@att.bizzzz> wrote:
>>>
>
>>
>>> IBM went through a similar phase: The only reason it hasn't been done is
>>> because nobody else has done it right. We've got the money to do it
>>> right.
>>
>>After a few billion$ were spent by others, why don't we flush a few more
>>of our stock holder's. Money's cheap.
>>
> I have no idea what Intel might do as a Plan B. I don't think there
> is a Plan B.

I agree (amazing, eh? ;) . AMD's caught them flat-footed with no Plan-B.
Dumb! Arrogance!

> I think Itanium is it. They would have been better off
> with Alpha?

I certainly think so. ...but they didn't own Alpha, so that's a moot point.

> I think that subject's been beaten to death. They needed something.

And needlessly pissed away their leadership on a dog, with *no* Plan-B.
Incredibly stupid. This is exactly what I've been saying for several
years. It's good to have you aboard! ;-)

>> The key problem that underlies at least some of Itanium's difficulties
>>> is a core problem for IT and it isn't going to go away: how to
>>> anticipate movement of data to minimize time on the critical path. The
>>> same problem shows up with memory access, with disk access, and now
>>> with serving web pages. The technology continues to move since
>>> Itanium was dreamed up. And who knows if they even understood how
>>> much of a problem getting the data in would be would be--I don't think
>>> they did.
>>
>>I guess Intel architects don't read CA? These issues were discussed
>>there whan Itanic was first announced.
>>
> I don't know what to say if you really think usenet posts to comp.arch
> are the last word on a subject.

If you think the people who poat there are stupid, ignore them at your own
perill. When there is a rotten fish around, chances are someone
who's fished before will smell it.


>>> I'd be
>>> grateful, in fact, for a citation that said that they did. Itanium
>>> was already on the launching pad before people started saying "Oh, my
>>> g*d" about the memory wall. Since Intel effectively made the same
>>> decision *again* with NetBurst, though, one is inclined to think that
>>> Intel continued to think it had a way to beat the problem. Wonder who
>>> was lying to whom?
>>
>>Itanic may have been on the launching pad before people discussed this,
>>but these people discussed these problems as soon as they saw the
>>monster. Apparently you don't think Intel's architects are as sharp as
>>those who publicly post to CA.
>
> I don't know what you mean. NetBurst was the same flavor of wishful
> thinking as Itanium: we'll figure out a way to get the compiler to
> schedule it, even if the processor has the agility of an oil tanker.

Perhaps you do know what I mean, after all. ;-)

>>> The advantage is that it's not x86 and it's not made by IBM. Your bet
>>> is that the industry will converge on x86. It may well, except for a
>>> particularly lucrative part of the market. That's the part that IBM
>>> has and that Intel wants. A different ISA won't help them to get it?
>>> Apparently Intel thinks otherwise.
>>
>>Why does "made by IBM" make it bad? A proprietary architecture is a
>>proprietary architecture (Itanic much more so than PowerPC, in fact).
>>Why would one take applications from a more or less open architecture
>>(x86) to a closed one? Why would you trust your enterprise to Intel as
>>opposed to IBM? ...particularly when one has a tad more experience in
>>the market.
>>
> *Somebody* is going to be using *some* architecture not proprietary to
> IBM to make high-end boxes. It doesn't matter whether I think it's good
> or bad. It's going to happen. If Itanium dies, it will be something
> else.

Well, HPaq killing Alpha, and Intel screwing the pooch on Itanic... ;-)

I certainly *hope* there will be something else. Mono-cultures are boring.

>>That was certainly Intel's plan. Too bad it was fatally flawed by a
>>turkey of an architecture. Intel needed a bust-out architecture to pull
>>anything like the off, but chose one that needed more than a little
>>invention than they could handle. Meanwhile everyone else scaled up
>>their performance. ...sorta what Intel (with x86) did to RISC.
>>
> Intel was not alone. Elbrus was going to conquer the world with its
> VLIW architecture. I think Intel bought whatever was left of Elbrus.

Whoopie! ...and it got them???

>>> It's true. When I talk to people who _ought_ to be interested,
>>> they're not. They've already tried it, found out that it's hard and
>>> there's no real payoff, and moved on.
>>
>>Meanwhile, AMD swiped Intel's lunch money. Intel doesn't show pretty
>>poor signs of catching up.
>
> For all that, Intel's feathers don't seem to be too ruffled. If it's
> all a bluff, they bluff very effectively.

Intel's feathers are certainly ruffled. The biz is in the dumps, so how
this plays is anyone's guess, but Intel has *nothing* to answer AMD with.
Indeed I'm shocked they didn't figure it out *long* before now. Instead
of trying to come up with a proprietary memory system (or whatever), I
would have thought a few bux spent in extending the architecture they'd
all but locked up would have been prudent. I guess the eight-figure club
doesn't think the same way simple engineers do.

--
Keith
Anonymous
a b à CPUs
May 15, 2005 3:29:11 AM

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

Robert Myers wrote:
>>Meanwhile, AMD swiped Intel's lunch money. Intel doesn't show pretty
>>poor signs of catching up.
>
>
> For all that, Intel's feathers don't seem to be too ruffled. If it's
> all a bluff, they bluff very effectively.

Mostly their feathers don't look ruffled because they've been able to
maintain their illegal incentives, which has kept manufacturers from
even trying out the competition.

Yousuf Khan
Anonymous
a b à CPUs
May 22, 2005 4:03:58 PM

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

Robert Myers <rmyers1400@comcast.net> wrote in
news:D 1i681hq9lsra8e7oicr6i61etn716pvf6@4ax.com:


So is this the

"No one ever got fired for going IBM line of thought"?

or the

"No one ever got fired for going Microsoft line of thought"?

ooops, they're the same thing. The type of response you'd expect from a
manager who has switched their brain to off.



>
> 3. AMD doesn't have the capacity to be Intel. That's the one that
> really counts for managers with their thinking caps on.
>
> RM
>
Anonymous
a b à CPUs
May 23, 2005 3:08:02 PM

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

No, it's the AMD can't possibly dominate the industry until it has more
capacity line of thought.

Those who bought IBM products can still get support from IBM, no matter
how old the machine. Got some dusty old deck that needs some ancient
compiler that ran on System 360? They still got it, 'cause they're
still here to have it. Who knows what the future may hold for AMD, but
Intel isn't going away.

I wouldn't count on Microsoft for yesterday's email, and I don't.

RM
May 24, 2005 1:07:15 AM

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

On Mon, 23 May 2005 11:08:02 -0700, rbmyersusa wrote:

> No, it's the AMD can't possibly dominate the industry until it has more
> capacity line of thought.
>
> Those who bought IBM products can still get support from IBM, no matter
> how old the machine. Got some dusty old deck that needs some ancient
> compiler that ran on System 360? They still got it,

Do you *really* believe that? Products are sunset all the time, with no
service.

> 'cause they're still here to have it. Who knows what the future may hold for AMD, but
> Intel isn't going away.

If the hardware is compatable, does it matter?

> I wouldn't count on Microsoft for yesterday's email, and I don't.

I wouldn't count on M$ with today's, but that's how they designed the
Win-World. ...somehow a lot of people do just that though.

--
Keith
Anonymous
a b à CPUs
May 24, 2005 9:53:01 AM

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

On Mon, 23 May 2005 21:07:15 -0400, keith <krw@att.bizzzz> wrote:

>On Mon, 23 May 2005 11:08:02 -0700, rbmyersusa wrote:
>
>> No, it's the AMD can't possibly dominate the industry until it has more
>> capacity line of thought.
>>
>> Those who bought IBM products can still get support from IBM, no matter
>> how old the machine. Got some dusty old deck that needs some ancient
>> compiler that ran on System 360? They still got it,
>
>Do you *really* believe that? Products are sunset all the time, with no
>service.
>
Oh, I worded my post to make it sound like hardware was supported
forever. What I meant to say was that software doesn't get stranded.
I've heard of cases where software has been stranded, but I haven't
heard of many.

>> 'cause they're still here to have it. Who knows what the future may hold for AMD, but
>> Intel isn't going away.
>
>If the hardware is compatable, does it matter?
>
What does "compatible" mean, and how do you test for it?

RM
Anonymous
a b à CPUs
May 24, 2005 4:33:20 PM

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

Del Cecchi wrote:
> 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?
>
> Just curious.

I certainly wouldn't want to test that out. Even in the days when that
stuff was current, it was hit and miss about compatibility.

Even though all of the same instructions exist in the instruction set,
lord knows if for some reason there might be a timing loop in there
dependent on an instruction that now goes several orders of magnitude
faster.

Backward compatibility probably should be attempted beyond a few years
old.

Yousuf Khan
Anonymous
a b à CPUs
May 24, 2005 4:56:15 PM

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

"Robert Myers" <rmyers1400@comcast.net> wrote in message
news:u3u591puh51ucigau8g1gd93g4past4ejb@4ax.com...
> On Mon, 23 May 2005 21:07:15 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Mon, 23 May 2005 11:08:02 -0700, rbmyersusa wrote:
>>
>>> No, it's the AMD can't possibly dominate the industry until it has more
>>> capacity line of thought.
>>>
>>> Those who bought IBM products can still get support from IBM, no matter
>>> how old the machine. Got some dusty old deck that needs some ancient
>>> compiler that ran on System 360? They still got it,
>>
>>Do you *really* believe that? Products are sunset all the time, with no
>>service.
>>
> Oh, I worded my post to make it sound like hardware was supported
> forever. What I meant to say was that software doesn't get stranded.
> I've heard of cases where software has been stranded, but I haven't
> heard of many.
>
>>> 'cause they're still here to have it. Who knows what the future may
>>> hold for AMD, but
>>> Intel isn't going away.
>>
>>If the hardware is compatable, does it matter?
>>
> What does "compatible" mean, and how do you test for it?
>
> RM
>
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?

Just curious.

del
Anonymous
a b à CPUs
May 24, 2005 8:35:47 PM

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

On Tue, 24 May 2005 12:56:15 -0500, "Del Cecchi"
<dcecchi.nospam@att.net> wrote:


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

Well, you would ask.

My ancient DOS word processor will *not* run under the command prompt
under Windows XP because it claims there are insufficient FILES in the
config.sys file.

Now, Windows XP doesn't use config.sys, and that information should be
in \windows\system32\config.nt, but increasing the FILES there to a
level that should be much higher than necessary doesn't fix it.

Who knows. Maybe somebody here does. Fortunately, I still have an
XT-compatible that runs actual DOS.

RM
May 25, 2005 2:19:36 AM

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

On Tue, 24 May 2005 05:53:01 -0400, Robert Myers wrote:

> On Mon, 23 May 2005 21:07:15 -0400, keith <krw@att.bizzzz> wrote:
>
>>On Mon, 23 May 2005 11:08:02 -0700, rbmyersusa wrote:
>>
>>> No, it's the AMD can't possibly dominate the industry until it has more
>>> capacity line of thought.
>>>
>>> Those who bought IBM products can still get support from IBM, no matter
>>> how old the machine. Got some dusty old deck that needs some ancient
>>> compiler that ran on System 360? They still got it,
>>
>>Do you *really* believe that? Products are sunset all the time, with no
>>service.
>>
> Oh, I worded my post to make it sound like hardware was supported
> forever. What I meant to say was that software doesn't get stranded.
> I've heard of cases where software has been stranded, but I haven't
> heard of many.

It happens all the time. It costs money to support products, even if
the bits are free.

>>> 'cause they're still here to have it. Who knows what the future may
>>> hold for AMD, but Intel isn't going away.
>>
>>If the hardware is compatable, does it matter?
>>
> What does "compatible" mean, and how do you test for it?

Are you saying that an AMD processor is somehow incompatible with an
Intel? ...that switching from one to another is a huge deal? COme on,
you can do better.

--
Keith
Anonymous
a b à CPUs
May 25, 2005 1:30:13 PM

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

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.

RM
Anonymous
a b à CPUs
May 25, 2005 1:40:02 PM

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

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?

RM
Anonymous
a b à CPUs
May 25, 2005 6:14:10 PM

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

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?

All it does is show that you know you don't have a leg to stand
on w.r.t. this compatibility issue and you are dodging the
question instead of giving a straight answer.


It works for enough people with money to
> spend and other things to think about.
>
> RM
>
Anonymous
a b à CPUs
May 25, 2005 7:59:39 PM

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

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.

--
Rgds, George Macdonald
Anonymous
a b à CPUs
May 26, 2005 12:40:41 AM

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

<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?
>
> RM
>
Same way you test a microsoft service pack before rolling it out company
wide?

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.

del
!