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
Facebook
Twitter
Instagram