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