Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: chic_hearne who wrote (109776)	5/8/2000 7:07:00 PM
From: Gopher Broke	Read Replies (1) \| Respond to of 1587083

Chic, Re: Questions on Itanium SGI made a similar mistake, hoping to drop their own MIPS processors in favor of Itanium. Unfortunately they let MIPS stagnate and so now they have real problems, trying to maintain credibility when their servers have only 400 MHz processors (albeit lots of them). IBM at least kept their options open, continuing to develop the PPC alternative. Anyway, you identify various physical concerns with Itanium hardware, but IMO the primary issue is one of complexity. IA64 is so much more complex than IA32 that it was bound to be an unstable platform for a very long time. In the target market for IA64, performance is very much secondary to stability. My question would relate to extrapolating the observed failure rates of IA64 systems currently under test. Putting aside performance, when do they project that an IA64 system (+ associated software) will have even remotely the same level of stability as an IA32/Linux server?

To: chic_hearne who wrote (109776)	5/8/2000 8:04:00 PM
From: Daniel Schuh	Read Replies (1) \| Respond to of 1587083

Funny thing, Chic. I got a brother who works at Sequent, which IBM bought, presumably somewhat for their IA64 multiprocessor. He's not a good source of gossip, though, last I talked to him he was repeating the "Merced is just proof of platform prototype, McKinley's the real deal" blather that was current from Intel at the time. That line seems to be in hibernation at the moment. Merced has been in big trouble for years. My own recollection was that it was originally supposed to ship in '97, that from a Microprocessor Report article from '95-'96 or something. I used to ask CS architecture professors about this regularly, they'd shake their heads. A lot of summer interns worked on it, which may be another part of the problem. The only real specifics I ever got was that too much was being expected from the compiler. I'm sure Intel could write a book about it, but if I had to guess, I'd say that, maybe, VLIW just isn't worth the trouble. Just offhand, I'd say it's particularly not worth the trouble for server-type usage, which tend to be heavily multiprocess-oriented by nature. VLIW is, in theory, good for extracting fine-grain parallelism out of a single task. The benefit for i/o intensive work is, uh, something of a head scratcher. Who knows, though, maybe it'll be really good. The other big deal is supposed to be 64 bit addressing, but 64 bit processors have been around awhile now too, the (former) DEC Alpha must be 10 years old. The thing that I find irritating about the long running Merced saga is the stifling effect it's had on computer architecture innovation in general. Sort of like Rambus, Intel decides how the world is supposed to go and everybody loses objectivity. Intel can be wrong, too, it's happened more than once. Cheers, Dan.